[GIT PULL] On-demand device probing

[GIT PULL] On-demand device probing

[Tomeu Vizoso]

Hi Rob,

here is the pull request you asked for, with no changes from the version
that I posted last to the list.

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
on-demand-probes-for-next

for you to fetch changes up to 587402133fe433759d2d535e5d92ead87fd7f615:

of/platform: Defer probes of registered devices (2015-10-14 10:08:23 +0200)

----------------------------------------------------------------
Tomeu Vizoso (20):
driver core: handle -EPROBE_DEFER from bus_type.match()
ARM: amba: Move reading of periphid to amba_match()
of/platform: Point to struct device from device node
of: add function to allow probing a device from a OF node
gpio: Probe GPIO drivers on demand
pinctrl: Probe pinctrl devices on demand
regulator: core: Probe regulators on demand
drm: Probe panels on demand
drm/tegra: Probe dpaux devices on demand
i2c: core: Probe i2c adapters and devices on demand
pwm: Probe PWM chip devices on demand
backlight: Probe backlight devices on demand
usb: phy: Probe phy devices on demand
clk: Probe clk providers on demand
pinctrl: Probe pinctrl devices on demand
phy: core: Probe phy providers on demand
dma: of: Probe DMA controllers on demand
power-supply: Probe power supplies on demand
driver core: Allow deferring probes until late init
of/platform: Defer probes of registered devices

drivers/amba/bus.c | 88
++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------
drivers/base/Kconfig | 18 ++++++++++++++++++
drivers/base/dd.c | 30 ++++++++++++++++++++++++++++--
drivers/clk/clk.c | 3 +++
drivers/dma/of-dma.c | 3 +++
drivers/gpio/gpiolib-of.c | 5 +++++
drivers/gpu/drm/drm_panel.c | 3 +++
drivers/gpu/drm/tegra/dpaux.c | 3 +++
drivers/i2c/i2c-core.c | 4 ++++
drivers/of/device.c | 61
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/of/platform.c | 30 ++++++++++++++++++------------
drivers/phy/phy-core.c | 3 +++
drivers/pinctrl/devicetree.c | 3 +++
drivers/power/power_supply_core.c | 3 +++
drivers/pwm/core.c | 3 +++
drivers/regulator/core.c | 2 ++
drivers/usb/phy/phy.c | 3 +++
drivers/video/backlight/backlight.c | 3 +++
include/linux/device.h | 4 +++-
include/linux/of.h | 1 +
include/linux/of_device.h | 3 +++
21 files changed, 219 insertions(+), 57 deletions(-)


Thanks,

Tomeu

[GIT PULL] On-demand device probing

[Tomeu Vizoso]

Hi Rob,

here is the pull request you asked for, with no changes from the version
that I posted last to the list.

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
on-demand-probes-for-next

for you to fetch changes up to 587402133fe433759d2d535e5d92ead87fd7f615:

of/platform: Defer probes of registered devices (2015-10-14 10:08:23 +0200)

----------------------------------------------------------------
Tomeu Vizoso (20):
driver core: handle -EPROBE_DEFER from bus_type.match()
ARM: amba: Move reading of periphid to amba_match()
of/platform: Point to struct device from device node
of: add function to allow probing a device from a OF node
gpio: Probe GPIO drivers on demand
pinctrl: Probe pinctrl devices on demand
regulator: core: Probe regulators on demand
drm: Probe panels on demand
drm/tegra: Probe dpaux devices on demand
i2c: core: Probe i2c adapters and devices on demand
pwm: Probe PWM chip devices on demand
backlight: Probe backlight devices on demand
usb: phy: Probe phy devices on demand
clk: Probe clk providers on demand
pinctrl: Probe pinctrl devices on demand
phy: core: Probe phy providers on demand
dma: of: Probe DMA controllers on demand
power-supply: Probe power supplies on demand
driver core: Allow deferring probes until late init
of/platform: Defer probes of registered devices

drivers/amba/bus.c | 88
++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------
drivers/base/Kconfig | 18 ++++++++++++++++++
drivers/base/dd.c | 30 ++++++++++++++++++++++++++++--
drivers/clk/clk.c | 3 +++
drivers/dma/of-dma.c | 3 +++
drivers/gpio/gpiolib-of.c | 5 +++++
drivers/gpu/drm/drm_panel.c | 3 +++
drivers/gpu/drm/tegra/dpaux.c | 3 +++
drivers/i2c/i2c-core.c | 4 ++++
drivers/of/device.c | 61
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/of/platform.c | 30 ++++++++++++++++++------------
drivers/phy/phy-core.c | 3 +++
drivers/pinctrl/devicetree.c | 3 +++
drivers/power/power_supply_core.c | 3 +++
drivers/pwm/core.c | 3 +++
drivers/regulator/core.c | 2 ++
drivers/usb/phy/phy.c | 3 +++
drivers/video/backlight/backlight.c | 3 +++
include/linux/device.h | 4 +++-
include/linux/of.h | 1 +
include/linux/of_device.h | 3 +++
21 files changed, 219 insertions(+), 57 deletions(-)


Thanks,

Tomeu

[GIT PULL] On-demand device probing

[Tomeu Vizoso]

Hi Rob,

here is the pull request you asked for, with no changes from the version
that I posted last to the list.

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
on-demand-probes-for-next

for you to fetch changes up to 587402133fe433759d2d535e5d92ead87fd7f615:

of/platform: Defer probes of registered devices (2015-10-14 10:08:23 +0200)

----------------------------------------------------------------
Tomeu Vizoso (20):
driver core: handle -EPROBE_DEFER from bus_type.match()
ARM: amba: Move reading of periphid to amba_match()
of/platform: Point to struct device from device node
of: add function to allow probing a device from a OF node
gpio: Probe GPIO drivers on demand
pinctrl: Probe pinctrl devices on demand
regulator: core: Probe regulators on demand
drm: Probe panels on demand
drm/tegra: Probe dpaux devices on demand
i2c: core: Probe i2c adapters and devices on demand
pwm: Probe PWM chip devices on demand
backlight: Probe backlight devices on demand
usb: phy: Probe phy devices on demand
clk: Probe clk providers on demand
pinctrl: Probe pinctrl devices on demand
phy: core: Probe phy providers on demand
dma: of: Probe DMA controllers on demand
power-supply: Probe power supplies on demand
driver core: Allow deferring probes until late init
of/platform: Defer probes of registered devices

drivers/amba/bus.c | 88
++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------
drivers/base/Kconfig | 18 ++++++++++++++++++
drivers/base/dd.c | 30 ++++++++++++++++++++++++++++--
drivers/clk/clk.c | 3 +++
drivers/dma/of-dma.c | 3 +++
drivers/gpio/gpiolib-of.c | 5 +++++
drivers/gpu/drm/drm_panel.c | 3 +++
drivers/gpu/drm/tegra/dpaux.c | 3 +++
drivers/i2c/i2c-core.c | 4 ++++
drivers/of/device.c | 61
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/of/platform.c | 30 ++++++++++++++++++------------
drivers/phy/phy-core.c | 3 +++
drivers/pinctrl/devicetree.c | 3 +++
drivers/power/power_supply_core.c | 3 +++
drivers/pwm/core.c | 3 +++
drivers/regulator/core.c | 2 ++
drivers/usb/phy/phy.c | 3 +++
drivers/video/backlight/backlight.c | 3 +++
include/linux/device.h | 4 +++-
include/linux/of.h | 1 +
include/linux/of_device.h | 3 +++
21 files changed, 219 insertions(+), 57 deletions(-)


Thanks,

Tomeu

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:

> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> on-demand-probes-for-next

In don't think that's the URL you intended to use (also everything looks
word wrapped here)?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:

> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> on-demand-probes-for-next

In don't think that's the URL you intended to use (also everything looks
word wrapped here)?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:

> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> on-demand-probes-for-next

In don't think that's the URL you intended to use (also everything looks
word wrapped here)?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[GIT PULL] On-demand device probing

[Tomeu Vizoso]

Hi,

this second pull request replaces the last references to device_initcall_sync with late_initcall, as noticed by Frank Rowand.

Also fixes the url of the git repo and the wrapping, as suggested by Mark Brown.

Thanks,

Tomeu

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  git://git.collabora.com/git/user/tomeu/linux.git on-demand-probes-for-next

for you to fetch changes up to c074fef5d36e1c27dfdf7474e23c01a1b044ff98:

  of/platform: Defer probes of registered devices (2015-10-15 13:25:47 +0200)

----------------------------------------------------------------
Tomeu Vizoso (20):
      driver core: handle -EPROBE_DEFER from bus_type.match()
      ARM: amba: Move reading of periphid to amba_match()
      of/platform: Point to struct device from device node
      of: add function to allow probing a device from a OF node
      gpio: Probe GPIO drivers on demand
      pinctrl: Probe pinctrl devices on demand
      regulator: core: Probe regulators on demand
      drm: Probe panels on demand
      drm/tegra: Probe dpaux devices on demand
      i2c: core: Probe i2c adapters and devices on demand
      pwm: Probe PWM chip devices on demand
      backlight: Probe backlight devices on demand
      usb: phy: Probe phy devices on demand
      clk: Probe clk providers on demand
      pinctrl: Probe pinctrl devices on demand
      phy: core: Probe phy providers on demand
      dma: of: Probe DMA controllers on demand
      power-supply: Probe power supplies on demand
      driver core: Allow deferring probes until late init
      of/platform: Defer probes of registered devices

 drivers/amba/bus.c                  | 88 +++++++++++++++++++------------------
 drivers/base/Kconfig                | 18 ++++++++
 drivers/base/dd.c                   | 30 ++++++++++++-
 drivers/clk/clk.c                   |  3 ++
 drivers/dma/of-dma.c                |  3 ++
 drivers/gpio/gpiolib-of.c           |  5 +++
 drivers/gpu/drm/drm_panel.c         |  3 ++
 drivers/gpu/drm/tegra/dpaux.c       |  3 ++
 drivers/i2c/i2c-core.c              |  4 ++
 drivers/of/device.c                 | 61 +++++++++++++++++++++++++
 drivers/of/platform.c               | 30 ++++++++-----
 drivers/phy/phy-core.c              |  3 ++
 drivers/pinctrl/devicetree.c        |  3 ++
 drivers/power/power_supply_core.c   |  3 ++
 drivers/pwm/core.c                  |  3 ++
 drivers/regulator/core.c            |  2 +
 drivers/usb/phy/phy.c               |  3 ++
 drivers/video/backlight/backlight.c |  3 ++
 include/linux/device.h              |  4 +-
 include/linux/of.h                  |  1 +
 include/linux/of_device.h           |  3 ++
 21 files changed, 219 insertions(+), 57 deletions(-)

[GIT PULL] On-demand device probing

[Tomeu Vizoso]

Hi,

this second pull request replaces the last references to device_initcall_sync with late_initcall, as noticed by Frank Rowand.

Also fixes the url of the git repo and the wrapping, as suggested by Mark Brown.

Thanks,

Tomeu

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  git://git.collabora.com/git/user/tomeu/linux.git on-demand-probes-for-next

for you to fetch changes up to c074fef5d36e1c27dfdf7474e23c01a1b044ff98:

  of/platform: Defer probes of registered devices (2015-10-15 13:25:47 +0200)

----------------------------------------------------------------
Tomeu Vizoso (20):
      driver core: handle -EPROBE_DEFER from bus_type.match()
      ARM: amba: Move reading of periphid to amba_match()
      of/platform: Point to struct device from device node
      of: add function to allow probing a device from a OF node
      gpio: Probe GPIO drivers on demand
      pinctrl: Probe pinctrl devices on demand
      regulator: core: Probe regulators on demand
      drm: Probe panels on demand
      drm/tegra: Probe dpaux devices on demand
      i2c: core: Probe i2c adapters and devices on demand
      pwm: Probe PWM chip devices on demand
      backlight: Probe backlight devices on demand
      usb: phy: Probe phy devices on demand
      clk: Probe clk providers on demand
      pinctrl: Probe pinctrl devices on demand
      phy: core: Probe phy providers on demand
      dma: of: Probe DMA controllers on demand
      power-supply: Probe power supplies on demand
      driver core: Allow deferring probes until late init
      of/platform: Defer probes of registered devices

 drivers/amba/bus.c                  | 88 +++++++++++++++++++------------------
 drivers/base/Kconfig                | 18 ++++++++
 drivers/base/dd.c                   | 30 ++++++++++++-
 drivers/clk/clk.c                   |  3 ++
 drivers/dma/of-dma.c                |  3 ++
 drivers/gpio/gpiolib-of.c           |  5 +++
 drivers/gpu/drm/drm_panel.c         |  3 ++
 drivers/gpu/drm/tegra/dpaux.c       |  3 ++
 drivers/i2c/i2c-core.c              |  4 ++
 drivers/of/device.c                 | 61 +++++++++++++++++++++++++
 drivers/of/platform.c               | 30 ++++++++-----
 drivers/phy/phy-core.c              |  3 ++
 drivers/pinctrl/devicetree.c        |  3 ++
 drivers/power/power_supply_core.c   |  3 ++
 drivers/pwm/core.c                  |  3 ++
 drivers/regulator/core.c            |  2 +
 drivers/usb/phy/phy.c               |  3 ++
 drivers/video/backlight/backlight.c |  3 ++
 include/linux/device.h              |  4 +-
 include/linux/of.h                  |  1 +
 include/linux/of_device.h           |  3 ++
 21 files changed, 219 insertions(+), 57 deletions(-)

[GIT PULL] On-demand device probing

[Tomeu Vizoso]

Hi,

this second pull request replaces the last references to device_initcall_sync with late_initcall, as noticed by Frank Rowand.

Also fixes the url of the git repo and the wrapping, as suggested by Mark Brown.

Thanks,

Tomeu

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  git://git.collabora.com/git/user/tomeu/linux.git on-demand-probes-for-next

for you to fetch changes up to c074fef5d36e1c27dfdf7474e23c01a1b044ff98:

  of/platform: Defer probes of registered devices (2015-10-15 13:25:47 +0200)

----------------------------------------------------------------
Tomeu Vizoso (20):
      driver core: handle -EPROBE_DEFER from bus_type.match()
      ARM: amba: Move reading of periphid to amba_match()
      of/platform: Point to struct device from device node
      of: add function to allow probing a device from a OF node
      gpio: Probe GPIO drivers on demand
      pinctrl: Probe pinctrl devices on demand
      regulator: core: Probe regulators on demand
      drm: Probe panels on demand
      drm/tegra: Probe dpaux devices on demand
      i2c: core: Probe i2c adapters and devices on demand
      pwm: Probe PWM chip devices on demand
      backlight: Probe backlight devices on demand
      usb: phy: Probe phy devices on demand
      clk: Probe clk providers on demand
      pinctrl: Probe pinctrl devices on demand
      phy: core: Probe phy providers on demand
      dma: of: Probe DMA controllers on demand
      power-supply: Probe power supplies on demand
      driver core: Allow deferring probes until late init
      of/platform: Defer probes of registered devices

 drivers/amba/bus.c                  | 88 +++++++++++++++++++------------------
 drivers/base/Kconfig                | 18 ++++++++
 drivers/base/dd.c                   | 30 ++++++++++++-
 drivers/clk/clk.c                   |  3 ++
 drivers/dma/of-dma.c                |  3 ++
 drivers/gpio/gpiolib-of.c           |  5 +++
 drivers/gpu/drm/drm_panel.c         |  3 ++
 drivers/gpu/drm/tegra/dpaux.c       |  3 ++
 drivers/i2c/i2c-core.c              |  4 ++
 drivers/of/device.c                 | 61 +++++++++++++++++++++++++
 drivers/of/platform.c               | 30 ++++++++-----
 drivers/phy/phy-core.c              |  3 ++
 drivers/pinctrl/devicetree.c        |  3 ++
 drivers/power/power_supply_core.c   |  3 ++
 drivers/pwm/core.c                  |  3 ++
 drivers/regulator/core.c            |  2 +
 drivers/usb/phy/phy.c               |  3 ++
 drivers/video/backlight/backlight.c |  3 ++
 include/linux/device.h              |  4 +-
 include/linux/of.h                  |  1 +
 include/linux/of_device.h           |  3 ++
 21 files changed, 219 insertions(+), 57 deletions(-)

Re: [GIT PULL] On-demand device probing

[Olof Johansson]

Hi,

I've bisected boot failures in next-20151016 down to patches in this branch:

On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
<tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> wrote:
> Tomeu Vizoso (20):
>       driver core: handle -EPROBE_DEFER from bus_type.match()

The machine it happened on was OMAP5UEVM:

http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html

But I've also seen it on tegra2, that one bisected down to:

>      regulator: core: Probe regulators on demand

http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html



-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Olof Johansson]

Hi,

I've bisected boot failures in next-20151016 down to patches in this branch:

On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
<tomeu.vizoso@collabora.com> wrote:
> Tomeu Vizoso (20):
>       driver core: handle -EPROBE_DEFER from bus_type.match()

The machine it happened on was OMAP5UEVM:

http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html

But I've also seen it on tegra2, that one bisected down to:

>      regulator: core: Probe regulators on demand

http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html



-Olof

Re: [GIT PULL] On-demand device probing

[Olof Johansson]

Hi,

I've bisected boot failures in next-20151016 down to patches in this branch:

On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
<tomeu.vizoso@collabora.com> wrote:
> Tomeu Vizoso (20):
>       driver core: handle -EPROBE_DEFER from bus_type.match()

The machine it happened on was OMAP5UEVM:

http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html

But I've also seen it on tegra2, that one bisected down to:

>      regulator: core: Probe regulators on demand

http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html



-Olof

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> Hi Rob,
> 
> here is the pull request you asked for, with no changes from the version
> that I posted last to the list.
> 
> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> 
> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> 
> are available in the git repository at:
> 
> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> on-demand-probes-for-next

That's not a signed tag :(

Anyway, I REALLY don't like this series (sorry for the delay in
reviewing them, normally I trust Rob's judgement...)

I can't see adding calls like this all over the tree just to solve a
bus-specific problem, you are adding of_* calls where they aren't
needed, or wanted, at all.

What is the root-problem of your delay in device probing?  I read your
last patch series and I can't seem to figure out what the issue is that
this is solving in any "better" way from the existing deferred probing.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> Hi Rob,
> 
> here is the pull request you asked for, with no changes from the version
> that I posted last to the list.
> 
> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> 
> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> 
> are available in the git repository at:
> 
> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> on-demand-probes-for-next

That's not a signed tag :(

Anyway, I REALLY don't like this series (sorry for the delay in
reviewing them, normally I trust Rob's judgement...)

I can't see adding calls like this all over the tree just to solve a
bus-specific problem, you are adding of_* calls where they aren't
needed, or wanted, at all.

What is the root-problem of your delay in device probing?  I read your
last patch series and I can't seem to figure out what the issue is that
this is solving in any "better" way from the existing deferred probing.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> Hi Rob,
> 
> here is the pull request you asked for, with no changes from the version
> that I posted last to the list.
> 
> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> 
> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> 
> are available in the git repository at:
> 
> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> on-demand-probes-for-next

That's not a signed tag :(

Anyway, I REALLY don't like this series (sorry for the delay in
reviewing them, normally I trust Rob's judgement...)

I can't see adding calls like this all over the tree just to solve a
bus-specific problem, you are adding of_* calls where they aren't
needed, or wanted, at all.

What is the root-problem of your delay in device probing?  I read your
last patch series and I can't seem to figure out what the issue is that
this is solving in any "better" way from the existing deferred probing.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
>> Hi Rob,
>>
>> here is the pull request you asked for, with no changes from the version
>> that I posted last to the list.
>>
>> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
>>
>> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
>>
>> are available in the git repository at:
>>
>> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
>> on-demand-probes-for-next
>
> That's not a signed tag :(
>
> Anyway, I REALLY don't like this series (sorry for the delay in
> reviewing them, normally I trust Rob's judgement...)

We've seen a lot of attempts here. This is really the best solution so
far in that it is simple, uses existing data from DT, and was low risk
for breaking platforms (at least I thought it would be). Anyway,
getting more exposure is why I've put it into -next.

> I can't see adding calls like this all over the tree just to solve a
> bus-specific problem, you are adding of_* calls where they aren't
> needed, or wanted, at all.

I think Linus W, Mark B, and I all said a similar thing initially in
that dependencies should be handled in the driver core. We went down
the path of making this not firmware (aka bus) specific and an earlier
version had just that (with fwnode_* calls). That turned out to be
pointless as the calling locations were almost always in DT specific
code anyway. If you notice, the calls are next to other DT specific
calls generally (usually a "get"). So yes, I'd prefer not to have to
touch every subsystem, but we had to do that anyway to add DT support.

We've generally split the DT code into the core (in drivers/of) and
the binding specific (in subsystems). Extracting dependency
information the DT is going to require binding specific knowledge, so
subsystem changes are probably unavoidable.

The alternative is we put binding specific knowledge into the core DT
code to parse dependencies.

> What is the root-problem of your delay in device probing?  I read your
> last patch series and I can't seem to figure out what the issue is that
> this is solving in any "better" way from the existing deferred probing.

It saves 2 seconds in the boot time as re-probing takes time. That
alone seems compelling to me.

Another downside to deferred probing is you have to touch every driver
and subsystem to support it. This contains the problem to the
subsystems.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
>> Hi Rob,
>>
>> here is the pull request you asked for, with no changes from the version
>> that I posted last to the list.
>>
>> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
>>
>> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
>>
>> are available in the git repository at:
>>
>> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
>> on-demand-probes-for-next
>
> That's not a signed tag :(
>
> Anyway, I REALLY don't like this series (sorry for the delay in
> reviewing them, normally I trust Rob's judgement...)

We've seen a lot of attempts here. This is really the best solution so
far in that it is simple, uses existing data from DT, and was low risk
for breaking platforms (at least I thought it would be). Anyway,
getting more exposure is why I've put it into -next.

> I can't see adding calls like this all over the tree just to solve a
> bus-specific problem, you are adding of_* calls where they aren't
> needed, or wanted, at all.

I think Linus W, Mark B, and I all said a similar thing initially in
that dependencies should be handled in the driver core. We went down
the path of making this not firmware (aka bus) specific and an earlier
version had just that (with fwnode_* calls). That turned out to be
pointless as the calling locations were almost always in DT specific
code anyway. If you notice, the calls are next to other DT specific
calls generally (usually a "get"). So yes, I'd prefer not to have to
touch every subsystem, but we had to do that anyway to add DT support.

We've generally split the DT code into the core (in drivers/of) and
the binding specific (in subsystems). Extracting dependency
information the DT is going to require binding specific knowledge, so
subsystem changes are probably unavoidable.

The alternative is we put binding specific knowledge into the core DT
code to parse dependencies.

> What is the root-problem of your delay in device probing?  I read your
> last patch series and I can't seem to figure out what the issue is that
> this is solving in any "better" way from the existing deferred probing.

It saves 2 seconds in the boot time as re-probing takes time. That
alone seems compelling to me.

Another downside to deferred probing is you have to touch every driver
and subsystem to support it. This contains the problem to the
subsystems.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
>> Hi Rob,
>>
>> here is the pull request you asked for, with no changes from the version
>> that I posted last to the list.
>>
>> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
>>
>> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
>>
>> are available in the git repository at:
>>
>> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
>> on-demand-probes-for-next
>
> That's not a signed tag :(
>
> Anyway, I REALLY don't like this series (sorry for the delay in
> reviewing them, normally I trust Rob's judgement...)

We've seen a lot of attempts here. This is really the best solution so
far in that it is simple, uses existing data from DT, and was low risk
for breaking platforms (at least I thought it would be). Anyway,
getting more exposure is why I've put it into -next.

> I can't see adding calls like this all over the tree just to solve a
> bus-specific problem, you are adding of_* calls where they aren't
> needed, or wanted, at all.

I think Linus W, Mark B, and I all said a similar thing initially in
that dependencies should be handled in the driver core. We went down
the path of making this not firmware (aka bus) specific and an earlier
version had just that (with fwnode_* calls). That turned out to be
pointless as the calling locations were almost always in DT specific
code anyway. If you notice, the calls are next to other DT specific
calls generally (usually a "get"). So yes, I'd prefer not to have to
touch every subsystem, but we had to do that anyway to add DT support.

We've generally split the DT code into the core (in drivers/of) and
the binding specific (in subsystems). Extracting dependency
information the DT is going to require binding specific knowledge, so
subsystem changes are probably unavoidable.

The alternative is we put binding specific knowledge into the core DT
code to parse dependencies.

> What is the root-problem of your delay in device probing?  I read your
> last patch series and I can't seem to figure out what the issue is that
> this is solving in any "better" way from the existing deferred probing.

It saves 2 seconds in the boot time as re-probing takes time. That
alone seems compelling to me.

Another downside to deferred probing is you have to touch every driver
and subsystem to support it. This contains the problem to the
subsystems.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson <olof@lixom.net> wrote:
> Hi,
>
> I've bisected boot failures in next-20151016 down to patches in this branch:
>
> On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
> <tomeu.vizoso@collabora.com> wrote:
>> Tomeu Vizoso (20):
>>       driver core: handle -EPROBE_DEFER from bus_type.match()
>
> The machine it happened on was OMAP5UEVM:
>
> http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html

So this one is because the MMC node numbering changed. I don't know
how to fix that other than with aliases, but that doesn't solve
backwards compatibility.


> But I've also seen it on tegra2, that one bisected down to:
>
>>      regulator: core: Probe regulators on demand
>
> http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html

This one you need a rootwait I think. The MMC scanning is not
guaranteed to be done before the rootfs mounting AFAIK. There may be
other problems, but we can't see them since it panics.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson <olof@lixom.net> wrote:
> Hi,
>
> I've bisected boot failures in next-20151016 down to patches in this branch:
>
> On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
> <tomeu.vizoso@collabora.com> wrote:
>> Tomeu Vizoso (20):
>>       driver core: handle -EPROBE_DEFER from bus_type.match()
>
> The machine it happened on was OMAP5UEVM:
>
> http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html

So this one is because the MMC node numbering changed. I don't know
how to fix that other than with aliases, but that doesn't solve
backwards compatibility.


> But I've also seen it on tegra2, that one bisected down to:
>
>>      regulator: core: Probe regulators on demand
>
> http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html

This one you need a rootwait I think. The MMC scanning is not
guaranteed to be done before the rootfs mounting AFAIK. There may be
other problems, but we can't see them since it panics.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson <olof@lixom.net> wrote:
> Hi,
>
> I've bisected boot failures in next-20151016 down to patches in this branch:
>
> On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
> <tomeu.vizoso@collabora.com> wrote:
>> Tomeu Vizoso (20):
>>       driver core: handle -EPROBE_DEFER from bus_type.match()
>
> The machine it happened on was OMAP5UEVM:
>
> http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html

So this one is because the MMC node numbering changed. I don't know
how to fix that other than with aliases, but that doesn't solve
backwards compatibility.


> But I've also seen it on tegra2, that one bisected down to:
>
>>      regulator: core: Probe regulators on demand
>
> http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html

This one you need a rootwait I think. The MMC scanning is not
guaranteed to be done before the rootfs mounting AFAIK. There may be
other problems, but we can't see them since it panics.

Rob

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> >> Hi Rob,
> >>
> >> here is the pull request you asked for, with no changes from the version
> >> that I posted last to the list.
> >>
> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> >>
> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> >>
> >> are available in the git repository at:
> >>
> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> >> on-demand-probes-for-next
> >
> > That's not a signed tag :(
> >
> > Anyway, I REALLY don't like this series (sorry for the delay in
> > reviewing them, normally I trust Rob's judgement...)
> 
> We've seen a lot of attempts here. This is really the best solution so
> far in that it is simple, uses existing data from DT, and was low risk
> for breaking platforms (at least I thought it would be). Anyway,
> getting more exposure is why I've put it into -next.

Exposure is good, now we know it breaks some builds, which was useful :)

> > I can't see adding calls like this all over the tree just to solve a
> > bus-specific problem, you are adding of_* calls where they aren't
> > needed, or wanted, at all.
> 
> I think Linus W, Mark B, and I all said a similar thing initially in
> that dependencies should be handled in the driver core. We went down
> the path of making this not firmware (aka bus) specific and an earlier
> version had just that (with fwnode_* calls). That turned out to be
> pointless as the calling locations were almost always in DT specific
> code anyway. If you notice, the calls are next to other DT specific
> calls generally (usually a "get"). So yes, I'd prefer not to have to
> touch every subsystem, but we had to do that anyway to add DT support.

If they are "next" to a call like that, why not put it in that call?  I
really object to having to "sprinkle" this all over the kernel, for no
obvious reason why that is happening at all (look at the USB patch for
one such example.)

> We've generally split the DT code into the core (in drivers/of) and
> the binding specific (in subsystems). Extracting dependency
> information the DT is going to require binding specific knowledge, so
> subsystem changes are probably unavoidable.
> 
> The alternative is we put binding specific knowledge into the core DT
> code to parse dependencies.
> 
> > What is the root-problem of your delay in device probing?  I read your
> > last patch series and I can't seem to figure out what the issue is that
> > this is solving in any "better" way from the existing deferred probing.
> 
> It saves 2 seconds in the boot time as re-probing takes time. That
> alone seems compelling to me.

2 seconds is _forever_, and really seems like some other driver is
sleeping and causing this problem.  What does the bootlog time-chart say
is really causing this long delay?  There's no way we are stuck in some
sort of logic loop for that long (i.e. having to walk the list of
devices somehow.)  This sounds like a driver-specific problem that is
being worked around by having to touch all subsystems, which isn't nice.

Hint, we didn't have to do this type of thing to solve boot delays on
x86 when we had hardware that was slow to initialize, why should DT be
special?  :)

> Another downside to deferred probing is you have to touch every driver
> and subsystem to support it. This contains the problem to the
> subsystems.

But we have deferred probing already, only those drivers that need/want
it have to do anything, why create yet-another model here?

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> >> Hi Rob,
> >>
> >> here is the pull request you asked for, with no changes from the version
> >> that I posted last to the list.
> >>
> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> >>
> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> >>
> >> are available in the git repository at:
> >>
> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> >> on-demand-probes-for-next
> >
> > That's not a signed tag :(
> >
> > Anyway, I REALLY don't like this series (sorry for the delay in
> > reviewing them, normally I trust Rob's judgement...)
> 
> We've seen a lot of attempts here. This is really the best solution so
> far in that it is simple, uses existing data from DT, and was low risk
> for breaking platforms (at least I thought it would be). Anyway,
> getting more exposure is why I've put it into -next.

Exposure is good, now we know it breaks some builds, which was useful :)

> > I can't see adding calls like this all over the tree just to solve a
> > bus-specific problem, you are adding of_* calls where they aren't
> > needed, or wanted, at all.
> 
> I think Linus W, Mark B, and I all said a similar thing initially in
> that dependencies should be handled in the driver core. We went down
> the path of making this not firmware (aka bus) specific and an earlier
> version had just that (with fwnode_* calls). That turned out to be
> pointless as the calling locations were almost always in DT specific
> code anyway. If you notice, the calls are next to other DT specific
> calls generally (usually a "get"). So yes, I'd prefer not to have to
> touch every subsystem, but we had to do that anyway to add DT support.

If they are "next" to a call like that, why not put it in that call?  I
really object to having to "sprinkle" this all over the kernel, for no
obvious reason why that is happening at all (look at the USB patch for
one such example.)

> We've generally split the DT code into the core (in drivers/of) and
> the binding specific (in subsystems). Extracting dependency
> information the DT is going to require binding specific knowledge, so
> subsystem changes are probably unavoidable.
> 
> The alternative is we put binding specific knowledge into the core DT
> code to parse dependencies.
> 
> > What is the root-problem of your delay in device probing?  I read your
> > last patch series and I can't seem to figure out what the issue is that
> > this is solving in any "better" way from the existing deferred probing.
> 
> It saves 2 seconds in the boot time as re-probing takes time. That
> alone seems compelling to me.

2 seconds is _forever_, and really seems like some other driver is
sleeping and causing this problem.  What does the bootlog time-chart say
is really causing this long delay?  There's no way we are stuck in some
sort of logic loop for that long (i.e. having to walk the list of
devices somehow.)  This sounds like a driver-specific problem that is
being worked around by having to touch all subsystems, which isn't nice.

Hint, we didn't have to do this type of thing to solve boot delays on
x86 when we had hardware that was slow to initialize, why should DT be
special?  :)

> Another downside to deferred probing is you have to touch every driver
> and subsystem to support it. This contains the problem to the
> subsystems.

But we have deferred probing already, only those drivers that need/want
it have to do anything, why create yet-another model here?

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> >> Hi Rob,
> >>
> >> here is the pull request you asked for, with no changes from the version
> >> that I posted last to the list.
> >>
> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> >>
> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> >>
> >> are available in the git repository at:
> >>
> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> >> on-demand-probes-for-next
> >
> > That's not a signed tag :(
> >
> > Anyway, I REALLY don't like this series (sorry for the delay in
> > reviewing them, normally I trust Rob's judgement...)
> 
> We've seen a lot of attempts here. This is really the best solution so
> far in that it is simple, uses existing data from DT, and was low risk
> for breaking platforms (at least I thought it would be). Anyway,
> getting more exposure is why I've put it into -next.

Exposure is good, now we know it breaks some builds, which was useful :)

> > I can't see adding calls like this all over the tree just to solve a
> > bus-specific problem, you are adding of_* calls where they aren't
> > needed, or wanted, at all.
> 
> I think Linus W, Mark B, and I all said a similar thing initially in
> that dependencies should be handled in the driver core. We went down
> the path of making this not firmware (aka bus) specific and an earlier
> version had just that (with fwnode_* calls). That turned out to be
> pointless as the calling locations were almost always in DT specific
> code anyway. If you notice, the calls are next to other DT specific
> calls generally (usually a "get"). So yes, I'd prefer not to have to
> touch every subsystem, but we had to do that anyway to add DT support.

If they are "next" to a call like that, why not put it in that call?  I
really object to having to "sprinkle" this all over the kernel, for no
obvious reason why that is happening at all (look at the USB patch for
one such example.)

> We've generally split the DT code into the core (in drivers/of) and
> the binding specific (in subsystems). Extracting dependency
> information the DT is going to require binding specific knowledge, so
> subsystem changes are probably unavoidable.
> 
> The alternative is we put binding specific knowledge into the core DT
> code to parse dependencies.
> 
> > What is the root-problem of your delay in device probing?  I read your
> > last patch series and I can't seem to figure out what the issue is that
> > this is solving in any "better" way from the existing deferred probing.
> 
> It saves 2 seconds in the boot time as re-probing takes time. That
> alone seems compelling to me.

2 seconds is _forever_, and really seems like some other driver is
sleeping and causing this problem.  What does the bootlog time-chart say
is really causing this long delay?  There's no way we are stuck in some
sort of logic loop for that long (i.e. having to walk the list of
devices somehow.)  This sounds like a driver-specific problem that is
being worked around by having to touch all subsystems, which isn't nice.

Hint, we didn't have to do this type of thing to solve boot delays on
x86 when we had hardware that was slow to initialize, why should DT be
special?  :)

> Another downside to deferred probing is you have to touch every driver
> and subsystem to support it. This contains the problem to the
> subsystems.

But we have deferred probing already, only those drivers that need/want
it have to do anything, why create yet-another model here?

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
>> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
>> >> Hi Rob,
>> >>
>> >> here is the pull request you asked for, with no changes from the version
>> >> that I posted last to the list.
>> >>
>> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
>> >>
>> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
>> >>
>> >> are available in the git repository at:
>> >>
>> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
>> >> on-demand-probes-for-next
>> >
>> > That's not a signed tag :(
>> >
>> > Anyway, I REALLY don't like this series (sorry for the delay in
>> > reviewing them, normally I trust Rob's judgement...)
>>
>> We've seen a lot of attempts here. This is really the best solution so
>> far in that it is simple, uses existing data from DT, and was low risk
>> for breaking platforms (at least I thought it would be). Anyway,
>> getting more exposure is why I've put it into -next.
>
> Exposure is good, now we know it breaks some builds, which was useful :)

Now that I've looked at them, they are somewhat questionable failures.
They do show the fragile nature of probe ordering and the implicit
dependencies we have.

>> > I can't see adding calls like this all over the tree just to solve a
>> > bus-specific problem, you are adding of_* calls where they aren't
>> > needed, or wanted, at all.
>>
>> I think Linus W, Mark B, and I all said a similar thing initially in
>> that dependencies should be handled in the driver core. We went down
>> the path of making this not firmware (aka bus) specific and an earlier
>> version had just that (with fwnode_* calls). That turned out to be
>> pointless as the calling locations were almost always in DT specific
>> code anyway. If you notice, the calls are next to other DT specific
>> calls generally (usually a "get"). So yes, I'd prefer not to have to
>> touch every subsystem, but we had to do that anyway to add DT support.
>
> If they are "next" to a call like that, why not put it in that call?  I
> really object to having to "sprinkle" this all over the kernel, for no
> obvious reason why that is happening at all (look at the USB patch for
> one such example.)

Looking at it again, they are in DT specific code already. The USB one
is in devm_usb_get_phy_by_node() which is a DT specific call.

>> We've generally split the DT code into the core (in drivers/of) and
>> the binding specific (in subsystems). Extracting dependency
>> information the DT is going to require binding specific knowledge, so
>> subsystem changes are probably unavoidable.
>>
>> The alternative is we put binding specific knowledge into the core DT
>> code to parse dependencies.
>>
>> > What is the root-problem of your delay in device probing?  I read your
>> > last patch series and I can't seem to figure out what the issue is that
>> > this is solving in any "better" way from the existing deferred probing.
>>
>> It saves 2 seconds in the boot time as re-probing takes time. That
>> alone seems compelling to me.
>
> 2 seconds is _forever_, and really seems like some other driver is
> sleeping and causing this problem.  What does the bootlog time-chart say
> is really causing this long delay?  There's no way we are stuck in some
> sort of logic loop for that long (i.e. having to walk the list of
> devices somehow.)  This sounds like a driver-specific problem that is
> being worked around by having to touch all subsystems, which isn't nice.

I don't think it is one driver as the improvement is seen on multiple
platforms. I'll let Tomeu comment further on where the time was spent.

> Hint, we didn't have to do this type of thing to solve boot delays on
> x86 when we had hardware that was slow to initialize, why should DT be
> special?  :)

x86 did not need deferred probe either (though we probably can find
some initcall ordering hacks). This is an embedded problem, not a DT
problem.

I'm guessing the time is a matter of probing and undoing the probes
rather than slow h/w. We could maybe improve things by making sure
drivers move what they defer on to the beginning of probe, but that
seems like a horrible, fragile hack.

>> Another downside to deferred probing is you have to touch every driver
>> and subsystem to support it. This contains the problem to the
>> subsystems.
>
> But we have deferred probing already, only those drivers that need/want
> it have to do anything, why create yet-another model here?

Yes, the only ones needing it are drivers dependent on clocks, gpio,
regulators, pwm, pin-ctrl, dma, etc. That's not a small number. This
is a side benefit and wouldn't take this series for that reason alone.

I've used the deferred probing is good enough argument myself on
previous attempts. The boot time improvements convinced me it is not
good enough except for simple cases.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
>> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
>> >> Hi Rob,
>> >>
>> >> here is the pull request you asked for, with no changes from the version
>> >> that I posted last to the list.
>> >>
>> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
>> >>
>> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
>> >>
>> >> are available in the git repository at:
>> >>
>> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
>> >> on-demand-probes-for-next
>> >
>> > That's not a signed tag :(
>> >
>> > Anyway, I REALLY don't like this series (sorry for the delay in
>> > reviewing them, normally I trust Rob's judgement...)
>>
>> We've seen a lot of attempts here. This is really the best solution so
>> far in that it is simple, uses existing data from DT, and was low risk
>> for breaking platforms (at least I thought it would be). Anyway,
>> getting more exposure is why I've put it into -next.
>
> Exposure is good, now we know it breaks some builds, which was useful :)

Now that I've looked at them, they are somewhat questionable failures.
They do show the fragile nature of probe ordering and the implicit
dependencies we have.

>> > I can't see adding calls like this all over the tree just to solve a
>> > bus-specific problem, you are adding of_* calls where they aren't
>> > needed, or wanted, at all.
>>
>> I think Linus W, Mark B, and I all said a similar thing initially in
>> that dependencies should be handled in the driver core. We went down
>> the path of making this not firmware (aka bus) specific and an earlier
>> version had just that (with fwnode_* calls). That turned out to be
>> pointless as the calling locations were almost always in DT specific
>> code anyway. If you notice, the calls are next to other DT specific
>> calls generally (usually a "get"). So yes, I'd prefer not to have to
>> touch every subsystem, but we had to do that anyway to add DT support.
>
> If they are "next" to a call like that, why not put it in that call?  I
> really object to having to "sprinkle" this all over the kernel, for no
> obvious reason why that is happening at all (look at the USB patch for
> one such example.)

Looking at it again, they are in DT specific code already. The USB one
is in devm_usb_get_phy_by_node() which is a DT specific call.

>> We've generally split the DT code into the core (in drivers/of) and
>> the binding specific (in subsystems). Extracting dependency
>> information the DT is going to require binding specific knowledge, so
>> subsystem changes are probably unavoidable.
>>
>> The alternative is we put binding specific knowledge into the core DT
>> code to parse dependencies.
>>
>> > What is the root-problem of your delay in device probing?  I read your
>> > last patch series and I can't seem to figure out what the issue is that
>> > this is solving in any "better" way from the existing deferred probing.
>>
>> It saves 2 seconds in the boot time as re-probing takes time. That
>> alone seems compelling to me.
>
> 2 seconds is _forever_, and really seems like some other driver is
> sleeping and causing this problem.  What does the bootlog time-chart say
> is really causing this long delay?  There's no way we are stuck in some
> sort of logic loop for that long (i.e. having to walk the list of
> devices somehow.)  This sounds like a driver-specific problem that is
> being worked around by having to touch all subsystems, which isn't nice.

I don't think it is one driver as the improvement is seen on multiple
platforms. I'll let Tomeu comment further on where the time was spent.

> Hint, we didn't have to do this type of thing to solve boot delays on
> x86 when we had hardware that was slow to initialize, why should DT be
> special?  :)

x86 did not need deferred probe either (though we probably can find
some initcall ordering hacks). This is an embedded problem, not a DT
problem.

I'm guessing the time is a matter of probing and undoing the probes
rather than slow h/w. We could maybe improve things by making sure
drivers move what they defer on to the beginning of probe, but that
seems like a horrible, fragile hack.

>> Another downside to deferred probing is you have to touch every driver
>> and subsystem to support it. This contains the problem to the
>> subsystems.
>
> But we have deferred probing already, only those drivers that need/want
> it have to do anything, why create yet-another model here?

Yes, the only ones needing it are drivers dependent on clocks, gpio,
regulators, pwm, pin-ctrl, dma, etc. That's not a small number. This
is a side benefit and wouldn't take this series for that reason alone.

I've used the deferred probing is good enough argument myself on
previous attempts. The boot time improvements convinced me it is not
good enough except for simple cases.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
>> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
>> >> Hi Rob,
>> >>
>> >> here is the pull request you asked for, with no changes from the version
>> >> that I posted last to the list.
>> >>
>> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
>> >>
>> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
>> >>
>> >> are available in the git repository at:
>> >>
>> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
>> >> on-demand-probes-for-next
>> >
>> > That's not a signed tag :(
>> >
>> > Anyway, I REALLY don't like this series (sorry for the delay in
>> > reviewing them, normally I trust Rob's judgement...)
>>
>> We've seen a lot of attempts here. This is really the best solution so
>> far in that it is simple, uses existing data from DT, and was low risk
>> for breaking platforms (at least I thought it would be). Anyway,
>> getting more exposure is why I've put it into -next.
>
> Exposure is good, now we know it breaks some builds, which was useful :)

Now that I've looked at them, they are somewhat questionable failures.
They do show the fragile nature of probe ordering and the implicit
dependencies we have.

>> > I can't see adding calls like this all over the tree just to solve a
>> > bus-specific problem, you are adding of_* calls where they aren't
>> > needed, or wanted, at all.
>>
>> I think Linus W, Mark B, and I all said a similar thing initially in
>> that dependencies should be handled in the driver core. We went down
>> the path of making this not firmware (aka bus) specific and an earlier
>> version had just that (with fwnode_* calls). That turned out to be
>> pointless as the calling locations were almost always in DT specific
>> code anyway. If you notice, the calls are next to other DT specific
>> calls generally (usually a "get"). So yes, I'd prefer not to have to
>> touch every subsystem, but we had to do that anyway to add DT support.
>
> If they are "next" to a call like that, why not put it in that call?  I
> really object to having to "sprinkle" this all over the kernel, for no
> obvious reason why that is happening at all (look at the USB patch for
> one such example.)

Looking at it again, they are in DT specific code already. The USB one
is in devm_usb_get_phy_by_node() which is a DT specific call.

>> We've generally split the DT code into the core (in drivers/of) and
>> the binding specific (in subsystems). Extracting dependency
>> information the DT is going to require binding specific knowledge, so
>> subsystem changes are probably unavoidable.
>>
>> The alternative is we put binding specific knowledge into the core DT
>> code to parse dependencies.
>>
>> > What is the root-problem of your delay in device probing?  I read your
>> > last patch series and I can't seem to figure out what the issue is that
>> > this is solving in any "better" way from the existing deferred probing.
>>
>> It saves 2 seconds in the boot time as re-probing takes time. That
>> alone seems compelling to me.
>
> 2 seconds is _forever_, and really seems like some other driver is
> sleeping and causing this problem.  What does the bootlog time-chart say
> is really causing this long delay?  There's no way we are stuck in some
> sort of logic loop for that long (i.e. having to walk the list of
> devices somehow.)  This sounds like a driver-specific problem that is
> being worked around by having to touch all subsystems, which isn't nice.

I don't think it is one driver as the improvement is seen on multiple
platforms. I'll let Tomeu comment further on where the time was spent.

> Hint, we didn't have to do this type of thing to solve boot delays on
> x86 when we had hardware that was slow to initialize, why should DT be
> special?  :)

x86 did not need deferred probe either (though we probably can find
some initcall ordering hacks). This is an embedded problem, not a DT
problem.

I'm guessing the time is a matter of probing and undoing the probes
rather than slow h/w. We could maybe improve things by making sure
drivers move what they defer on to the beginning of probe, but that
seems like a horrible, fragile hack.

>> Another downside to deferred probing is you have to touch every driver
>> and subsystem to support it. This contains the problem to the
>> subsystems.
>
> But we have deferred probing already, only those drivers that need/want
> it have to do anything, why create yet-another model here?

Yes, the only ones needing it are drivers dependent on clocks, gpio,
regulators, pwm, pin-ctrl, dma, etc. That's not a small number. This
is a side benefit and wouldn't take this series for that reason alone.

I've used the deferred probing is good enough argument myself on
previous attempts. The boot time improvements convinced me it is not
good enough except for simple cases.

Rob

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 11:28:29AM -0500, Rob Herring wrote:
> On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
> >> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> >> >> Hi Rob,
> >> >>
> >> >> here is the pull request you asked for, with no changes from the version
> >> >> that I posted last to the list.
> >> >>
> >> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> >> >>
> >> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> >> >>
> >> >> are available in the git repository at:
> >> >>
> >> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> >> >> on-demand-probes-for-next
> >> >
> >> > That's not a signed tag :(
> >> >
> >> > Anyway, I REALLY don't like this series (sorry for the delay in
> >> > reviewing them, normally I trust Rob's judgement...)
> >>
> >> We've seen a lot of attempts here. This is really the best solution so
> >> far in that it is simple, uses existing data from DT, and was low risk
> >> for breaking platforms (at least I thought it would be). Anyway,
> >> getting more exposure is why I've put it into -next.
> >
> > Exposure is good, now we know it breaks some builds, which was useful :)
> 
> Now that I've looked at them, they are somewhat questionable failures.
> They do show the fragile nature of probe ordering and the implicit
> dependencies we have.
> 
> >> > I can't see adding calls like this all over the tree just to solve a
> >> > bus-specific problem, you are adding of_* calls where they aren't
> >> > needed, or wanted, at all.
> >>
> >> I think Linus W, Mark B, and I all said a similar thing initially in
> >> that dependencies should be handled in the driver core. We went down
> >> the path of making this not firmware (aka bus) specific and an earlier
> >> version had just that (with fwnode_* calls). That turned out to be
> >> pointless as the calling locations were almost always in DT specific
> >> code anyway. If you notice, the calls are next to other DT specific
> >> calls generally (usually a "get"). So yes, I'd prefer not to have to
> >> touch every subsystem, but we had to do that anyway to add DT support.
> >
> > If they are "next" to a call like that, why not put it in that call?  I
> > really object to having to "sprinkle" this all over the kernel, for no
> > obvious reason why that is happening at all (look at the USB patch for
> > one such example.)
> 
> Looking at it again, they are in DT specific code already. The USB one
> is in devm_usb_get_phy_by_node() which is a DT specific call.

But that's not very obvious, right?  Especially given that you now have
to add a new .h file, which implies that suddenly this file is now
touching a new subsystem.

> >> We've generally split the DT code into the core (in drivers/of) and
> >> the binding specific (in subsystems). Extracting dependency
> >> information the DT is going to require binding specific knowledge, so
> >> subsystem changes are probably unavoidable.
> >>
> >> The alternative is we put binding specific knowledge into the core DT
> >> code to parse dependencies.
> >>
> >> > What is the root-problem of your delay in device probing?  I read your
> >> > last patch series and I can't seem to figure out what the issue is that
> >> > this is solving in any "better" way from the existing deferred probing.
> >>
> >> It saves 2 seconds in the boot time as re-probing takes time. That
> >> alone seems compelling to me.
> >
> > 2 seconds is _forever_, and really seems like some other driver is
> > sleeping and causing this problem.  What does the bootlog time-chart say
> > is really causing this long delay?  There's no way we are stuck in some
> > sort of logic loop for that long (i.e. having to walk the list of
> > devices somehow.)  This sounds like a driver-specific problem that is
> > being worked around by having to touch all subsystems, which isn't nice.
> 
> I don't think it is one driver as the improvement is seen on multiple
> platforms. I'll let Tomeu comment further on where the time was spent.

That would be good to know, as 2 seconds is forever (my whole machine
boots to a gnome login faster than that.)

> > Hint, we didn't have to do this type of thing to solve boot delays on
> > x86 when we had hardware that was slow to initialize, why should DT be
> > special?  :)
> 
> x86 did not need deferred probe either (though we probably can find
> some initcall ordering hacks). This is an embedded problem, not a DT
> problem.

x86 is embedded :)

> I'm guessing the time is a matter of probing and undoing the probes
> rather than slow h/w. We could maybe improve things by making sure
> drivers move what they defer on to the beginning of probe, but that
> seems like a horrible, fragile hack.

How can calling probe and failing cause 2 seconds?  How many different
probe calls are failing here?  Again, a boot log graph would be great to
see as it will show the root cause, not just guessing at this.

> >> Another downside to deferred probing is you have to touch every driver
> >> and subsystem to support it. This contains the problem to the
> >> subsystems.
> >
> > But we have deferred probing already, only those drivers that need/want
> > it have to do anything, why create yet-another model here?
> 
> Yes, the only ones needing it are drivers dependent on clocks, gpio,
> regulators, pwm, pin-ctrl, dma, etc. That's not a small number. This
> is a side benefit and wouldn't take this series for that reason alone.
> 
> I've used the deferred probing is good enough argument myself on
> previous attempts. The boot time improvements convinced me it is not
> good enough except for simple cases.

Then let's fix deferred probing to do it "correctly", let's not add
yet-another-way-to-probe instead please, as we will be forever
sprinkling these calls around subsystems in a cargo-cult-like manner for
forever.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 11:28:29AM -0500, Rob Herring wrote:
> On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
> >> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> >> >> Hi Rob,
> >> >>
> >> >> here is the pull request you asked for, with no changes from the version
> >> >> that I posted last to the list.
> >> >>
> >> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> >> >>
> >> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> >> >>
> >> >> are available in the git repository at:
> >> >>
> >> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> >> >> on-demand-probes-for-next
> >> >
> >> > That's not a signed tag :(
> >> >
> >> > Anyway, I REALLY don't like this series (sorry for the delay in
> >> > reviewing them, normally I trust Rob's judgement...)
> >>
> >> We've seen a lot of attempts here. This is really the best solution so
> >> far in that it is simple, uses existing data from DT, and was low risk
> >> for breaking platforms (at least I thought it would be). Anyway,
> >> getting more exposure is why I've put it into -next.
> >
> > Exposure is good, now we know it breaks some builds, which was useful :)
> 
> Now that I've looked at them, they are somewhat questionable failures.
> They do show the fragile nature of probe ordering and the implicit
> dependencies we have.
> 
> >> > I can't see adding calls like this all over the tree just to solve a
> >> > bus-specific problem, you are adding of_* calls where they aren't
> >> > needed, or wanted, at all.
> >>
> >> I think Linus W, Mark B, and I all said a similar thing initially in
> >> that dependencies should be handled in the driver core. We went down
> >> the path of making this not firmware (aka bus) specific and an earlier
> >> version had just that (with fwnode_* calls). That turned out to be
> >> pointless as the calling locations were almost always in DT specific
> >> code anyway. If you notice, the calls are next to other DT specific
> >> calls generally (usually a "get"). So yes, I'd prefer not to have to
> >> touch every subsystem, but we had to do that anyway to add DT support.
> >
> > If they are "next" to a call like that, why not put it in that call?  I
> > really object to having to "sprinkle" this all over the kernel, for no
> > obvious reason why that is happening at all (look at the USB patch for
> > one such example.)
> 
> Looking at it again, they are in DT specific code already. The USB one
> is in devm_usb_get_phy_by_node() which is a DT specific call.

But that's not very obvious, right?  Especially given that you now have
to add a new .h file, which implies that suddenly this file is now
touching a new subsystem.

> >> We've generally split the DT code into the core (in drivers/of) and
> >> the binding specific (in subsystems). Extracting dependency
> >> information the DT is going to require binding specific knowledge, so
> >> subsystem changes are probably unavoidable.
> >>
> >> The alternative is we put binding specific knowledge into the core DT
> >> code to parse dependencies.
> >>
> >> > What is the root-problem of your delay in device probing?  I read your
> >> > last patch series and I can't seem to figure out what the issue is that
> >> > this is solving in any "better" way from the existing deferred probing.
> >>
> >> It saves 2 seconds in the boot time as re-probing takes time. That
> >> alone seems compelling to me.
> >
> > 2 seconds is _forever_, and really seems like some other driver is
> > sleeping and causing this problem.  What does the bootlog time-chart say
> > is really causing this long delay?  There's no way we are stuck in some
> > sort of logic loop for that long (i.e. having to walk the list of
> > devices somehow.)  This sounds like a driver-specific problem that is
> > being worked around by having to touch all subsystems, which isn't nice.
> 
> I don't think it is one driver as the improvement is seen on multiple
> platforms. I'll let Tomeu comment further on where the time was spent.

That would be good to know, as 2 seconds is forever (my whole machine
boots to a gnome login faster than that.)

> > Hint, we didn't have to do this type of thing to solve boot delays on
> > x86 when we had hardware that was slow to initialize, why should DT be
> > special?  :)
> 
> x86 did not need deferred probe either (though we probably can find
> some initcall ordering hacks). This is an embedded problem, not a DT
> problem.

x86 is embedded :)

> I'm guessing the time is a matter of probing and undoing the probes
> rather than slow h/w. We could maybe improve things by making sure
> drivers move what they defer on to the beginning of probe, but that
> seems like a horrible, fragile hack.

How can calling probe and failing cause 2 seconds?  How many different
probe calls are failing here?  Again, a boot log graph would be great to
see as it will show the root cause, not just guessing at this.

> >> Another downside to deferred probing is you have to touch every driver
> >> and subsystem to support it. This contains the problem to the
> >> subsystems.
> >
> > But we have deferred probing already, only those drivers that need/want
> > it have to do anything, why create yet-another model here?
> 
> Yes, the only ones needing it are drivers dependent on clocks, gpio,
> regulators, pwm, pin-ctrl, dma, etc. That's not a small number. This
> is a side benefit and wouldn't take this series for that reason alone.
> 
> I've used the deferred probing is good enough argument myself on
> previous attempts. The boot time improvements convinced me it is not
> good enough except for simple cases.

Then let's fix deferred probing to do it "correctly", let's not add
yet-another-way-to-probe instead please, as we will be forever
sprinkling these calls around subsystems in a cargo-cult-like manner for
forever.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 11:28:29AM -0500, Rob Herring wrote:
> On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
> >> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> >> >> Hi Rob,
> >> >>
> >> >> here is the pull request you asked for, with no changes from the version
> >> >> that I posted last to the list.
> >> >>
> >> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> >> >>
> >> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> >> >>
> >> >> are available in the git repository at:
> >> >>
> >> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> >> >> on-demand-probes-for-next
> >> >
> >> > That's not a signed tag :(
> >> >
> >> > Anyway, I REALLY don't like this series (sorry for the delay in
> >> > reviewing them, normally I trust Rob's judgement...)
> >>
> >> We've seen a lot of attempts here. This is really the best solution so
> >> far in that it is simple, uses existing data from DT, and was low risk
> >> for breaking platforms (at least I thought it would be). Anyway,
> >> getting more exposure is why I've put it into -next.
> >
> > Exposure is good, now we know it breaks some builds, which was useful :)
> 
> Now that I've looked at them, they are somewhat questionable failures.
> They do show the fragile nature of probe ordering and the implicit
> dependencies we have.
> 
> >> > I can't see adding calls like this all over the tree just to solve a
> >> > bus-specific problem, you are adding of_* calls where they aren't
> >> > needed, or wanted, at all.
> >>
> >> I think Linus W, Mark B, and I all said a similar thing initially in
> >> that dependencies should be handled in the driver core. We went down
> >> the path of making this not firmware (aka bus) specific and an earlier
> >> version had just that (with fwnode_* calls). That turned out to be
> >> pointless as the calling locations were almost always in DT specific
> >> code anyway. If you notice, the calls are next to other DT specific
> >> calls generally (usually a "get"). So yes, I'd prefer not to have to
> >> touch every subsystem, but we had to do that anyway to add DT support.
> >
> > If they are "next" to a call like that, why not put it in that call?  I
> > really object to having to "sprinkle" this all over the kernel, for no
> > obvious reason why that is happening at all (look at the USB patch for
> > one such example.)
> 
> Looking at it again, they are in DT specific code already. The USB one
> is in devm_usb_get_phy_by_node() which is a DT specific call.

But that's not very obvious, right?  Especially given that you now have
to add a new .h file, which implies that suddenly this file is now
touching a new subsystem.

> >> We've generally split the DT code into the core (in drivers/of) and
> >> the binding specific (in subsystems). Extracting dependency
> >> information the DT is going to require binding specific knowledge, so
> >> subsystem changes are probably unavoidable.
> >>
> >> The alternative is we put binding specific knowledge into the core DT
> >> code to parse dependencies.
> >>
> >> > What is the root-problem of your delay in device probing?  I read your
> >> > last patch series and I can't seem to figure out what the issue is that
> >> > this is solving in any "better" way from the existing deferred probing.
> >>
> >> It saves 2 seconds in the boot time as re-probing takes time. That
> >> alone seems compelling to me.
> >
> > 2 seconds is _forever_, and really seems like some other driver is
> > sleeping and causing this problem.  What does the bootlog time-chart say
> > is really causing this long delay?  There's no way we are stuck in some
> > sort of logic loop for that long (i.e. having to walk the list of
> > devices somehow.)  This sounds like a driver-specific problem that is
> > being worked around by having to touch all subsystems, which isn't nice.
> 
> I don't think it is one driver as the improvement is seen on multiple
> platforms. I'll let Tomeu comment further on where the time was spent.

That would be good to know, as 2 seconds is forever (my whole machine
boots to a gnome login faster than that.)

> > Hint, we didn't have to do this type of thing to solve boot delays on
> > x86 when we had hardware that was slow to initialize, why should DT be
> > special?  :)
> 
> x86 did not need deferred probe either (though we probably can find
> some initcall ordering hacks). This is an embedded problem, not a DT
> problem.

x86 is embedded :)

> I'm guessing the time is a matter of probing and undoing the probes
> rather than slow h/w. We could maybe improve things by making sure
> drivers move what they defer on to the beginning of probe, but that
> seems like a horrible, fragile hack.

How can calling probe and failing cause 2 seconds?  How many different
probe calls are failing here?  Again, a boot log graph would be great to
see as it will show the root cause, not just guessing at this.

> >> Another downside to deferred probing is you have to touch every driver
> >> and subsystem to support it. This contains the problem to the
> >> subsystems.
> >
> > But we have deferred probing already, only those drivers that need/want
> > it have to do anything, why create yet-another model here?
> 
> Yes, the only ones needing it are drivers dependent on clocks, gpio,
> regulators, pwm, pin-ctrl, dma, etc. That's not a small number. This
> is a side benefit and wouldn't take this series for that reason alone.
> 
> I've used the deferred probing is good enough argument myself on
> previous attempts. The boot time improvements convinced me it is not
> good enough except for simple cases.

Then let's fix deferred probing to do it "correctly", let's not add
yet-another-way-to-probe instead please, as we will be forever
sprinkling these calls around subsystems in a cargo-cult-like manner for
forever.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Rob Clark]

On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>> I'm guessing the time is a matter of probing and undoing the probes
>> rather than slow h/w. We could maybe improve things by making sure
>> drivers move what they defer on to the beginning of probe, but that
>> seems like a horrible, fragile hack.
>
> How can calling probe and failing cause 2 seconds?  How many different
> probe calls are failing here?  Again, a boot log graph would be great to
> see as it will show the root cause, not just guessing at this.


just fwiw, but when you have a driver that depends on several other
drivers (which in turn depend on other drivers and so on), the amount
of probe-defer we end up seeing is pretty comical.  Yeah, there
probably is some room to optimize by juggling around order drivers do
things in probe.  But that doesn't solve the fundamental problem with
the current state, about probe order having no clue about
dependencies..

BR,
-R

Re: [GIT PULL] On-demand device probing

[Rob Clark]

On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>> I'm guessing the time is a matter of probing and undoing the probes
>> rather than slow h/w. We could maybe improve things by making sure
>> drivers move what they defer on to the beginning of probe, but that
>> seems like a horrible, fragile hack.
>
> How can calling probe and failing cause 2 seconds?  How many different
> probe calls are failing here?  Again, a boot log graph would be great to
> see as it will show the root cause, not just guessing at this.


just fwiw, but when you have a driver that depends on several other
drivers (which in turn depend on other drivers and so on), the amount
of probe-defer we end up seeing is pretty comical.  Yeah, there
probably is some room to optimize by juggling around order drivers do
things in probe.  But that doesn't solve the fundamental problem with
the current state, about probe order having no clue about
dependencies..

BR,
-R

Re: [GIT PULL] On-demand device probing

[Rob Clark]

On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>> I'm guessing the time is a matter of probing and undoing the probes
>> rather than slow h/w. We could maybe improve things by making sure
>> drivers move what they defer on to the beginning of probe, but that
>> seems like a horrible, fragile hack.
>
> How can calling probe and failing cause 2 seconds?  How many different
> probe calls are failing here?  Again, a boot log graph would be great to
> see as it will show the root cause, not just guessing at this.


just fwiw, but when you have a driver that depends on several other
drivers (which in turn depend on other drivers and so on), the amount
of probe-defer we end up seeing is pretty comical.  Yeah, there
probably is some room to optimize by juggling around order drivers do
things in probe.  But that doesn't solve the fundamental problem with
the current state, about probe order having no clue about
dependencies..

BR,
-R

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >> I'm guessing the time is a matter of probing and undoing the probes
> >> rather than slow h/w. We could maybe improve things by making sure
> >> drivers move what they defer on to the beginning of probe, but that
> >> seems like a horrible, fragile hack.
> >
> > How can calling probe and failing cause 2 seconds?  How many different
> > probe calls are failing here?  Again, a boot log graph would be great to
> > see as it will show the root cause, not just guessing at this.
> 
> 
> just fwiw, but when you have a driver that depends on several other
> drivers (which in turn depend on other drivers and so on), the amount
> of probe-defer we end up seeing is pretty comical.  Yeah, there
> probably is some room to optimize by juggling around order drivers do
> things in probe.  But that doesn't solve the fundamental problem with
> the current state, about probe order having no clue about
> dependencies..

I can imagine it is a lot of iterations, but how long does it really
take?  How many different devices are involved that it takes multiple
loops in order to finally work out the correct order?  Where is the time
delays here, just calling probe() and having it instantly return
shouldn't take all that long.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >> I'm guessing the time is a matter of probing and undoing the probes
> >> rather than slow h/w. We could maybe improve things by making sure
> >> drivers move what they defer on to the beginning of probe, but that
> >> seems like a horrible, fragile hack.
> >
> > How can calling probe and failing cause 2 seconds?  How many different
> > probe calls are failing here?  Again, a boot log graph would be great to
> > see as it will show the root cause, not just guessing at this.
> 
> 
> just fwiw, but when you have a driver that depends on several other
> drivers (which in turn depend on other drivers and so on), the amount
> of probe-defer we end up seeing is pretty comical.  Yeah, there
> probably is some room to optimize by juggling around order drivers do
> things in probe.  But that doesn't solve the fundamental problem with
> the current state, about probe order having no clue about
> dependencies..

I can imagine it is a lot of iterations, but how long does it really
take?  How many different devices are involved that it takes multiple
loops in order to finally work out the correct order?  Where is the time
delays here, just calling probe() and having it instantly return
shouldn't take all that long.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >> I'm guessing the time is a matter of probing and undoing the probes
> >> rather than slow h/w. We could maybe improve things by making sure
> >> drivers move what they defer on to the beginning of probe, but that
> >> seems like a horrible, fragile hack.
> >
> > How can calling probe and failing cause 2 seconds?  How many different
> > probe calls are failing here?  Again, a boot log graph would be great to
> > see as it will show the root cause, not just guessing at this.
> 
> 
> just fwiw, but when you have a driver that depends on several other
> drivers (which in turn depend on other drivers and so on), the amount
> of probe-defer we end up seeing is pretty comical.  Yeah, there
> probably is some room to optimize by juggling around order drivers do
> things in probe.  But that doesn't solve the fundamental problem with
> the current state, about probe order having no clue about
> dependencies..

I can imagine it is a lot of iterations, but how long does it really
take?  How many different devices are involved that it takes multiple
loops in order to finally work out the correct order?  Where is the time
delays here, just calling probe() and having it instantly return
shouldn't take all that long.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Rob Clark]

On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> >> I'm guessing the time is a matter of probing and undoing the probes
>> >> rather than slow h/w. We could maybe improve things by making sure
>> >> drivers move what they defer on to the beginning of probe, but that
>> >> seems like a horrible, fragile hack.
>> >
>> > How can calling probe and failing cause 2 seconds?  How many different
>> > probe calls are failing here?  Again, a boot log graph would be great to
>> > see as it will show the root cause, not just guessing at this.
>>
>>
>> just fwiw, but when you have a driver that depends on several other
>> drivers (which in turn depend on other drivers and so on), the amount
>> of probe-defer we end up seeing is pretty comical.  Yeah, there
>> probably is some room to optimize by juggling around order drivers do
>> things in probe.  But that doesn't solve the fundamental problem with
>> the current state, about probe order having no clue about
>> dependencies..
>
> I can imagine it is a lot of iterations, but how long does it really
> take?  How many different devices are involved that it takes multiple
> loops in order to finally work out the correct order?  Where is the time
> delays here, just calling probe() and having it instantly return
> shouldn't take all that long.

offhand, I think the dependencies go at *least* three levels deep..
I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
get all the way through requesting it's various different
regulators/clks/gpios.  I hadn't really paid attention to how many
tries the drivers I depend on go through.  (Of those, I take clks from
two different clk drivers (which have dependency on a 3rd clk driver),
and regulators and gpio's come from at least two places, which in turn
have dependencies on clks, etc.)  I don't have really good hard
numbers handy (since my observations of this are w/ console over uart
which effects timings, and so I see it taking much longer than 2sec)..
but the 2sec figure that Tomeu mentioned seemed pretty plausible to
me.

I can try to get better #'s... I should have my kernel hat on at least
some of the time next week.. but the 2sec figure didn't seem
unrealistic to me.

Just as an aside, the amount of probe-defer adds quite a lot of noise
when you are trying to debug why some driver doesn't probe
successfully.  Which itself would be a nice reason to do something
more clever..

BR,
-R


> thanks,
>
> greg k-h

Re: [GIT PULL] On-demand device probing

[Rob Clark]

On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> >> I'm guessing the time is a matter of probing and undoing the probes
>> >> rather than slow h/w. We could maybe improve things by making sure
>> >> drivers move what they defer on to the beginning of probe, but that
>> >> seems like a horrible, fragile hack.
>> >
>> > How can calling probe and failing cause 2 seconds?  How many different
>> > probe calls are failing here?  Again, a boot log graph would be great to
>> > see as it will show the root cause, not just guessing at this.
>>
>>
>> just fwiw, but when you have a driver that depends on several other
>> drivers (which in turn depend on other drivers and so on), the amount
>> of probe-defer we end up seeing is pretty comical.  Yeah, there
>> probably is some room to optimize by juggling around order drivers do
>> things in probe.  But that doesn't solve the fundamental problem with
>> the current state, about probe order having no clue about
>> dependencies..
>
> I can imagine it is a lot of iterations, but how long does it really
> take?  How many different devices are involved that it takes multiple
> loops in order to finally work out the correct order?  Where is the time
> delays here, just calling probe() and having it instantly return
> shouldn't take all that long.

offhand, I think the dependencies go at *least* three levels deep..
I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
get all the way through requesting it's various different
regulators/clks/gpios.  I hadn't really paid attention to how many
tries the drivers I depend on go through.  (Of those, I take clks from
two different clk drivers (which have dependency on a 3rd clk driver),
and regulators and gpio's come from at least two places, which in turn
have dependencies on clks, etc.)  I don't have really good hard
numbers handy (since my observations of this are w/ console over uart
which effects timings, and so I see it taking much longer than 2sec)..
but the 2sec figure that Tomeu mentioned seemed pretty plausible to
me.

I can try to get better #'s... I should have my kernel hat on at least
some of the time next week.. but the 2sec figure didn't seem
unrealistic to me.

Just as an aside, the amount of probe-defer adds quite a lot of noise
when you are trying to debug why some driver doesn't probe
successfully.  Which itself would be a nice reason to do something
more clever..

BR,
-R


> thanks,
>
> greg k-h

Re: [GIT PULL] On-demand device probing

[Rob Clark]

On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> >> I'm guessing the time is a matter of probing and undoing the probes
>> >> rather than slow h/w. We could maybe improve things by making sure
>> >> drivers move what they defer on to the beginning of probe, but that
>> >> seems like a horrible, fragile hack.
>> >
>> > How can calling probe and failing cause 2 seconds?  How many different
>> > probe calls are failing here?  Again, a boot log graph would be great to
>> > see as it will show the root cause, not just guessing at this.
>>
>>
>> just fwiw, but when you have a driver that depends on several other
>> drivers (which in turn depend on other drivers and so on), the amount
>> of probe-defer we end up seeing is pretty comical.  Yeah, there
>> probably is some room to optimize by juggling around order drivers do
>> things in probe.  But that doesn't solve the fundamental problem with
>> the current state, about probe order having no clue about
>> dependencies..
>
> I can imagine it is a lot of iterations, but how long does it really
> take?  How many different devices are involved that it takes multiple
> loops in order to finally work out the correct order?  Where is the time
> delays here, just calling probe() and having it instantly return
> shouldn't take all that long.

offhand, I think the dependencies go at *least* three levels deep..
I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
get all the way through requesting it's various different
regulators/clks/gpios.  I hadn't really paid attention to how many
tries the drivers I depend on go through.  (Of those, I take clks from
two different clk drivers (which have dependency on a 3rd clk driver),
and regulators and gpio's come from at least two places, which in turn
have dependencies on clks, etc.)  I don't have really good hard
numbers handy (since my observations of this are w/ console over uart
which effects timings, and so I see it taking much longer than 2sec)..
but the 2sec figure that Tomeu mentioned seemed pretty plausible to
me.

I can try to get better #'s... I should have my kernel hat on at least
some of the time next week.. but the 2sec figure didn't seem
unrealistic to me.

Just as an aside, the amount of probe-defer adds quite a lot of noise
when you are trying to debug why some driver doesn't probe
successfully.  Which itself would be a nice reason to do something
more clever..

BR,
-R


> thanks,
>
> greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> >> I'm guessing the time is a matter of probing and undoing the probes
> >> >> rather than slow h/w. We could maybe improve things by making sure
> >> >> drivers move what they defer on to the beginning of probe, but that
> >> >> seems like a horrible, fragile hack.
> >> >
> >> > How can calling probe and failing cause 2 seconds?  How many different
> >> > probe calls are failing here?  Again, a boot log graph would be great to
> >> > see as it will show the root cause, not just guessing at this.
> >>
> >>
> >> just fwiw, but when you have a driver that depends on several other
> >> drivers (which in turn depend on other drivers and so on), the amount
> >> of probe-defer we end up seeing is pretty comical.  Yeah, there
> >> probably is some room to optimize by juggling around order drivers do
> >> things in probe.  But that doesn't solve the fundamental problem with
> >> the current state, about probe order having no clue about
> >> dependencies..
> >
> > I can imagine it is a lot of iterations, but how long does it really
> > take?  How many different devices are involved that it takes multiple
> > loops in order to finally work out the correct order?  Where is the time
> > delays here, just calling probe() and having it instantly return
> > shouldn't take all that long.
> 
> offhand, I think the dependencies go at *least* three levels deep..
> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> get all the way through requesting it's various different
> regulators/clks/gpios.

And how long does that really take?  Numbers please :)

> I hadn't really paid attention to how many
> tries the drivers I depend on go through.  (Of those, I take clks from
> two different clk drivers (which have dependency on a 3rd clk driver),
> and regulators and gpio's come from at least two places, which in turn
> have dependencies on clks, etc.)  I don't have really good hard
> numbers handy (since my observations of this are w/ console over uart
> which effects timings, and so I see it taking much longer than 2sec)..
> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> me.
> 
> I can try to get better #'s... I should have my kernel hat on at least
> some of the time next week.. but the 2sec figure didn't seem
> unrealistic to me.

Based on the time it takes a modern laptop to boot, 2 seconds is
forever, there has to be something else going on here other than just
calling probe() a bunch of times.  Please use the tools we have to
determine this before trying to change the driver core.

> Just as an aside, the amount of probe-defer adds quite a lot of noise
> when you are trying to debug why some driver doesn't probe
> successfully.  Which itself would be a nice reason to do something
> more clever..

People seem to not like the noise, so let's turn off those messages,
that should speed things up :)

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> >> I'm guessing the time is a matter of probing and undoing the probes
> >> >> rather than slow h/w. We could maybe improve things by making sure
> >> >> drivers move what they defer on to the beginning of probe, but that
> >> >> seems like a horrible, fragile hack.
> >> >
> >> > How can calling probe and failing cause 2 seconds?  How many different
> >> > probe calls are failing here?  Again, a boot log graph would be great to
> >> > see as it will show the root cause, not just guessing at this.
> >>
> >>
> >> just fwiw, but when you have a driver that depends on several other
> >> drivers (which in turn depend on other drivers and so on), the amount
> >> of probe-defer we end up seeing is pretty comical.  Yeah, there
> >> probably is some room to optimize by juggling around order drivers do
> >> things in probe.  But that doesn't solve the fundamental problem with
> >> the current state, about probe order having no clue about
> >> dependencies..
> >
> > I can imagine it is a lot of iterations, but how long does it really
> > take?  How many different devices are involved that it takes multiple
> > loops in order to finally work out the correct order?  Where is the time
> > delays here, just calling probe() and having it instantly return
> > shouldn't take all that long.
> 
> offhand, I think the dependencies go at *least* three levels deep..
> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> get all the way through requesting it's various different
> regulators/clks/gpios.

And how long does that really take?  Numbers please :)

> I hadn't really paid attention to how many
> tries the drivers I depend on go through.  (Of those, I take clks from
> two different clk drivers (which have dependency on a 3rd clk driver),
> and regulators and gpio's come from at least two places, which in turn
> have dependencies on clks, etc.)  I don't have really good hard
> numbers handy (since my observations of this are w/ console over uart
> which effects timings, and so I see it taking much longer than 2sec)..
> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> me.
> 
> I can try to get better #'s... I should have my kernel hat on at least
> some of the time next week.. but the 2sec figure didn't seem
> unrealistic to me.

Based on the time it takes a modern laptop to boot, 2 seconds is
forever, there has to be something else going on here other than just
calling probe() a bunch of times.  Please use the tools we have to
determine this before trying to change the driver core.

> Just as an aside, the amount of probe-defer adds quite a lot of noise
> when you are trying to debug why some driver doesn't probe
> successfully.  Which itself would be a nice reason to do something
> more clever..

People seem to not like the noise, so let's turn off those messages,
that should speed things up :)

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> >> I'm guessing the time is a matter of probing and undoing the probes
> >> >> rather than slow h/w. We could maybe improve things by making sure
> >> >> drivers move what they defer on to the beginning of probe, but that
> >> >> seems like a horrible, fragile hack.
> >> >
> >> > How can calling probe and failing cause 2 seconds?  How many different
> >> > probe calls are failing here?  Again, a boot log graph would be great to
> >> > see as it will show the root cause, not just guessing at this.
> >>
> >>
> >> just fwiw, but when you have a driver that depends on several other
> >> drivers (which in turn depend on other drivers and so on), the amount
> >> of probe-defer we end up seeing is pretty comical.  Yeah, there
> >> probably is some room to optimize by juggling around order drivers do
> >> things in probe.  But that doesn't solve the fundamental problem with
> >> the current state, about probe order having no clue about
> >> dependencies..
> >
> > I can imagine it is a lot of iterations, but how long does it really
> > take?  How many different devices are involved that it takes multiple
> > loops in order to finally work out the correct order?  Where is the time
> > delays here, just calling probe() and having it instantly return
> > shouldn't take all that long.
> 
> offhand, I think the dependencies go at *least* three levels deep..
> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> get all the way through requesting it's various different
> regulators/clks/gpios.

And how long does that really take?  Numbers please :)

> I hadn't really paid attention to how many
> tries the drivers I depend on go through.  (Of those, I take clks from
> two different clk drivers (which have dependency on a 3rd clk driver),
> and regulators and gpio's come from at least two places, which in turn
> have dependencies on clks, etc.)  I don't have really good hard
> numbers handy (since my observations of this are w/ console over uart
> which effects timings, and so I see it taking much longer than 2sec)..
> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> me.
> 
> I can try to get better #'s... I should have my kernel hat on at least
> some of the time next week.. but the 2sec figure didn't seem
> unrealistic to me.

Based on the time it takes a modern laptop to boot, 2 seconds is
forever, there has to be something else going on here other than just
calling probe() a bunch of times.  Please use the tools we have to
determine this before trying to change the driver core.

> Just as an aside, the amount of probe-defer adds quite a lot of noise
> when you are trying to debug why some driver doesn't probe
> successfully.  Which itself would be a nice reason to do something
> more clever..

People seem to not like the noise, so let's turn off those messages,
that should speed things up :)

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Noralf Trønnes]

Den 17.10.2015 20:45, skrev Rob Clark:
> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>>> <gregkh@linuxfoundation.org> wrote:
>>>>> I'm guessing the time is a matter of probing and undoing the probes
>>>>> rather than slow h/w. We could maybe improve things by making sure
>>>>> drivers move what they defer on to the beginning of probe, but that
>>>>> seems like a horrible, fragile hack.
>>>> How can calling probe and failing cause 2 seconds?  How many different
>>>> probe calls are failing here?  Again, a boot log graph would be great to
>>>> see as it will show the root cause, not just guessing at this.
>>>
>>> just fwiw, but when you have a driver that depends on several other
>>> drivers (which in turn depend on other drivers and so on), the amount
>>> of probe-defer we end up seeing is pretty comical.  Yeah, there
>>> probably is some room to optimize by juggling around order drivers do
>>> things in probe.  But that doesn't solve the fundamental problem with
>>> the current state, about probe order having no clue about
>>> dependencies..
>> I can imagine it is a lot of iterations, but how long does it really
>> take?  How many different devices are involved that it takes multiple
>> loops in order to finally work out the correct order?  Where is the time
>> delays here, just calling probe() and having it instantly return
>> shouldn't take all that long.
> offhand, I think the dependencies go at *least* three levels deep..
> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> get all the way through requesting it's various different
> regulators/clks/gpios.  I hadn't really paid attention to how many
> tries the drivers I depend on go through.  (Of those, I take clks from
> two different clk drivers (which have dependency on a 3rd clk driver),
> and regulators and gpio's come from at least two places, which in turn
> have dependencies on clks, etc.)  I don't have really good hard
> numbers handy (since my observations of this are w/ console over uart
> which effects timings, and so I see it taking much longer than 2sec)..
> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> me.
>
> I can try to get better #'s... I should have my kernel hat on at least
> some of the time next week.. but the 2sec figure didn't seem
> unrealistic to me.

Are you saying that the total boot time is increased by 2 sec due to
deferred probing, or that display initialization is happening 2 sec
after it's first try?

Re: [GIT PULL] On-demand device probing

[Noralf Trønnes]

Den 17.10.2015 20:45, skrev Rob Clark:
> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>>> <gregkh@linuxfoundation.org> wrote:
>>>>> I'm guessing the time is a matter of probing and undoing the probes
>>>>> rather than slow h/w. We could maybe improve things by making sure
>>>>> drivers move what they defer on to the beginning of probe, but that
>>>>> seems like a horrible, fragile hack.
>>>> How can calling probe and failing cause 2 seconds?  How many different
>>>> probe calls are failing here?  Again, a boot log graph would be great to
>>>> see as it will show the root cause, not just guessing at this.
>>>
>>> just fwiw, but when you have a driver that depends on several other
>>> drivers (which in turn depend on other drivers and so on), the amount
>>> of probe-defer we end up seeing is pretty comical.  Yeah, there
>>> probably is some room to optimize by juggling around order drivers do
>>> things in probe.  But that doesn't solve the fundamental problem with
>>> the current state, about probe order having no clue about
>>> dependencies..
>> I can imagine it is a lot of iterations, but how long does it really
>> take?  How many different devices are involved that it takes multiple
>> loops in order to finally work out the correct order?  Where is the time
>> delays here, just calling probe() and having it instantly return
>> shouldn't take all that long.
> offhand, I think the dependencies go at *least* three levels deep..
> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> get all the way through requesting it's various different
> regulators/clks/gpios.  I hadn't really paid attention to how many
> tries the drivers I depend on go through.  (Of those, I take clks from
> two different clk drivers (which have dependency on a 3rd clk driver),
> and regulators and gpio's come from at least two places, which in turn
> have dependencies on clks, etc.)  I don't have really good hard
> numbers handy (since my observations of this are w/ console over uart
> which effects timings, and so I see it taking much longer than 2sec)..
> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> me.
>
> I can try to get better #'s... I should have my kernel hat on at least
> some of the time next week.. but the 2sec figure didn't seem
> unrealistic to me.

Are you saying that the total boot time is increased by 2 sec due to
deferred probing, or that display initialization is happening 2 sec
after it's first try?

Re: [GIT PULL] On-demand device probing

[Noralf Trønnes]

Den 17.10.2015 20:45, skrev Rob Clark:
> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>>> <gregkh@linuxfoundation.org> wrote:
>>>>> I'm guessing the time is a matter of probing and undoing the probes
>>>>> rather than slow h/w. We could maybe improve things by making sure
>>>>> drivers move what they defer on to the beginning of probe, but that
>>>>> seems like a horrible, fragile hack.
>>>> How can calling probe and failing cause 2 seconds?  How many different
>>>> probe calls are failing here?  Again, a boot log graph would be great to
>>>> see as it will show the root cause, not just guessing at this.
>>>
>>> just fwiw, but when you have a driver that depends on several other
>>> drivers (which in turn depend on other drivers and so on), the amount
>>> of probe-defer we end up seeing is pretty comical.  Yeah, there
>>> probably is some room to optimize by juggling around order drivers do
>>> things in probe.  But that doesn't solve the fundamental problem with
>>> the current state, about probe order having no clue about
>>> dependencies..
>> I can imagine it is a lot of iterations, but how long does it really
>> take?  How many different devices are involved that it takes multiple
>> loops in order to finally work out the correct order?  Where is the time
>> delays here, just calling probe() and having it instantly return
>> shouldn't take all that long.
> offhand, I think the dependencies go at *least* three levels deep..
> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> get all the way through requesting it's various different
> regulators/clks/gpios.  I hadn't really paid attention to how many
> tries the drivers I depend on go through.  (Of those, I take clks from
> two different clk drivers (which have dependency on a 3rd clk driver),
> and regulators and gpio's come from at least two places, which in turn
> have dependencies on clks, etc.)  I don't have really good hard
> numbers handy (since my observations of this are w/ console over uart
> which effects timings, and so I see it taking much longer than 2sec)..
> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> me.
>
> I can try to get better #'s... I should have my kernel hat on at least
> some of the time next week.. but the 2sec figure didn't seem
> unrealistic to me.

Are you saying that the total boot time is increased by 2 sec due to
deferred probing, or that display initialization is happening 2 sec
after it's first try?

Re: [GIT PULL] On-demand device probing

[Rob Clark]

On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
>> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>> >> <gregkh@linuxfoundation.org> wrote:
>> >> >> I'm guessing the time is a matter of probing and undoing the probes
>> >> >> rather than slow h/w. We could maybe improve things by making sure
>> >> >> drivers move what they defer on to the beginning of probe, but that
>> >> >> seems like a horrible, fragile hack.
>> >> >
>> >> > How can calling probe and failing cause 2 seconds?  How many different
>> >> > probe calls are failing here?  Again, a boot log graph would be great to
>> >> > see as it will show the root cause, not just guessing at this.
>> >>
>> >>
>> >> just fwiw, but when you have a driver that depends on several other
>> >> drivers (which in turn depend on other drivers and so on), the amount
>> >> of probe-defer we end up seeing is pretty comical.  Yeah, there
>> >> probably is some room to optimize by juggling around order drivers do
>> >> things in probe.  But that doesn't solve the fundamental problem with
>> >> the current state, about probe order having no clue about
>> >> dependencies..
>> >
>> > I can imagine it is a lot of iterations, but how long does it really
>> > take?  How many different devices are involved that it takes multiple
>> > loops in order to finally work out the correct order?  Where is the time
>> > delays here, just calling probe() and having it instantly return
>> > shouldn't take all that long.
>>
>> offhand, I think the dependencies go at *least* three levels deep..
>> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
>> get all the way through requesting it's various different
>> regulators/clks/gpios.
>
> And how long does that really take?  Numbers please :)
>
>> I hadn't really paid attention to how many
>> tries the drivers I depend on go through.  (Of those, I take clks from
>> two different clk drivers (which have dependency on a 3rd clk driver),
>> and regulators and gpio's come from at least two places, which in turn
>> have dependencies on clks, etc.)  I don't have really good hard
>> numbers handy (since my observations of this are w/ console over uart
>> which effects timings, and so I see it taking much longer than 2sec)..
>> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
>> me.
>>
>> I can try to get better #'s... I should have my kernel hat on at least
>> some of the time next week.. but the 2sec figure didn't seem
>> unrealistic to me.
>
> Based on the time it takes a modern laptop to boot, 2 seconds is
> forever, there has to be something else going on here other than just
> calling probe() a bunch of times.  Please use the tools we have to
> determine this before trying to change the driver core.

yes, I am aware of the tools.. although so far I spend most of my time
just trying to get things working in the first place ;-)

All I was trying to point out was that Tomeu's figures didn't really
seem unrealistic.  I mean, given that the average SoC driver probably
depends on at least one clock and at least one regulator, having to
probe each driver at least twice seems plausible.  And that having a
noticeable effect on boot time doesn't seem surprising.  I'm not sure
that saying 'modern laptop can boot in 2sec' adds much to the
discussion since I don't think you have quite so much interdependency
between devices vs random probe order.  I have seen arm devices boot
to UI in similar times, but that was pre-devicetree days.

I expect Tomeu has some better number.. if not I can collect some.

>> Just as an aside, the amount of probe-defer adds quite a lot of noise
>> when you are trying to debug why some driver doesn't probe
>> successfully.  Which itself would be a nice reason to do something
>> more clever..
>
> People seem to not like the noise, so let's turn off those messages,
> that should speed things up :)

heh, except for when you are trying to debug what is missing
preventing the driver you depend on from probing ;-)

BR,
-R

Re: [GIT PULL] On-demand device probing

[Rob Clark]

On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
>> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>> >> <gregkh@linuxfoundation.org> wrote:
>> >> >> I'm guessing the time is a matter of probing and undoing the probes
>> >> >> rather than slow h/w. We could maybe improve things by making sure
>> >> >> drivers move what they defer on to the beginning of probe, but that
>> >> >> seems like a horrible, fragile hack.
>> >> >
>> >> > How can calling probe and failing cause 2 seconds?  How many different
>> >> > probe calls are failing here?  Again, a boot log graph would be great to
>> >> > see as it will show the root cause, not just guessing at this.
>> >>
>> >>
>> >> just fwiw, but when you have a driver that depends on several other
>> >> drivers (which in turn depend on other drivers and so on), the amount
>> >> of probe-defer we end up seeing is pretty comical.  Yeah, there
>> >> probably is some room to optimize by juggling around order drivers do
>> >> things in probe.  But that doesn't solve the fundamental problem with
>> >> the current state, about probe order having no clue about
>> >> dependencies..
>> >
>> > I can imagine it is a lot of iterations, but how long does it really
>> > take?  How many different devices are involved that it takes multiple
>> > loops in order to finally work out the correct order?  Where is the time
>> > delays here, just calling probe() and having it instantly return
>> > shouldn't take all that long.
>>
>> offhand, I think the dependencies go at *least* three levels deep..
>> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
>> get all the way through requesting it's various different
>> regulators/clks/gpios.
>
> And how long does that really take?  Numbers please :)
>
>> I hadn't really paid attention to how many
>> tries the drivers I depend on go through.  (Of those, I take clks from
>> two different clk drivers (which have dependency on a 3rd clk driver),
>> and regulators and gpio's come from at least two places, which in turn
>> have dependencies on clks, etc.)  I don't have really good hard
>> numbers handy (since my observations of this are w/ console over uart
>> which effects timings, and so I see it taking much longer than 2sec)..
>> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
>> me.
>>
>> I can try to get better #'s... I should have my kernel hat on at least
>> some of the time next week.. but the 2sec figure didn't seem
>> unrealistic to me.
>
> Based on the time it takes a modern laptop to boot, 2 seconds is
> forever, there has to be something else going on here other than just
> calling probe() a bunch of times.  Please use the tools we have to
> determine this before trying to change the driver core.

yes, I am aware of the tools.. although so far I spend most of my time
just trying to get things working in the first place ;-)

All I was trying to point out was that Tomeu's figures didn't really
seem unrealistic.  I mean, given that the average SoC driver probably
depends on at least one clock and at least one regulator, having to
probe each driver at least twice seems plausible.  And that having a
noticeable effect on boot time doesn't seem surprising.  I'm not sure
that saying 'modern laptop can boot in 2sec' adds much to the
discussion since I don't think you have quite so much interdependency
between devices vs random probe order.  I have seen arm devices boot
to UI in similar times, but that was pre-devicetree days.

I expect Tomeu has some better number.. if not I can collect some.

>> Just as an aside, the amount of probe-defer adds quite a lot of noise
>> when you are trying to debug why some driver doesn't probe
>> successfully.  Which itself would be a nice reason to do something
>> more clever..
>
> People seem to not like the noise, so let's turn off those messages,
> that should speed things up :)

heh, except for when you are trying to debug what is missing
preventing the driver you depend on from probing ;-)

BR,
-R

Re: [GIT PULL] On-demand device probing

[Rob Clark]

On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
>> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>> >> <gregkh@linuxfoundation.org> wrote:
>> >> >> I'm guessing the time is a matter of probing and undoing the probes
>> >> >> rather than slow h/w. We could maybe improve things by making sure
>> >> >> drivers move what they defer on to the beginning of probe, but that
>> >> >> seems like a horrible, fragile hack.
>> >> >
>> >> > How can calling probe and failing cause 2 seconds?  How many different
>> >> > probe calls are failing here?  Again, a boot log graph would be great to
>> >> > see as it will show the root cause, not just guessing at this.
>> >>
>> >>
>> >> just fwiw, but when you have a driver that depends on several other
>> >> drivers (which in turn depend on other drivers and so on), the amount
>> >> of probe-defer we end up seeing is pretty comical.  Yeah, there
>> >> probably is some room to optimize by juggling around order drivers do
>> >> things in probe.  But that doesn't solve the fundamental problem with
>> >> the current state, about probe order having no clue about
>> >> dependencies..
>> >
>> > I can imagine it is a lot of iterations, but how long does it really
>> > take?  How many different devices are involved that it takes multiple
>> > loops in order to finally work out the correct order?  Where is the time
>> > delays here, just calling probe() and having it instantly return
>> > shouldn't take all that long.
>>
>> offhand, I think the dependencies go at *least* three levels deep..
>> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
>> get all the way through requesting it's various different
>> regulators/clks/gpios.
>
> And how long does that really take?  Numbers please :)
>
>> I hadn't really paid attention to how many
>> tries the drivers I depend on go through.  (Of those, I take clks from
>> two different clk drivers (which have dependency on a 3rd clk driver),
>> and regulators and gpio's come from at least two places, which in turn
>> have dependencies on clks, etc.)  I don't have really good hard
>> numbers handy (since my observations of this are w/ console over uart
>> which effects timings, and so I see it taking much longer than 2sec)..
>> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
>> me.
>>
>> I can try to get better #'s... I should have my kernel hat on at least
>> some of the time next week.. but the 2sec figure didn't seem
>> unrealistic to me.
>
> Based on the time it takes a modern laptop to boot, 2 seconds is
> forever, there has to be something else going on here other than just
> calling probe() a bunch of times.  Please use the tools we have to
> determine this before trying to change the driver core.

yes, I am aware of the tools.. although so far I spend most of my time
just trying to get things working in the first place ;-)

All I was trying to point out was that Tomeu's figures didn't really
seem unrealistic.  I mean, given that the average SoC driver probably
depends on at least one clock and at least one regulator, having to
probe each driver at least twice seems plausible.  And that having a
noticeable effect on boot time doesn't seem surprising.  I'm not sure
that saying 'modern laptop can boot in 2sec' adds much to the
discussion since I don't think you have quite so much interdependency
between devices vs random probe order.  I have seen arm devices boot
to UI in similar times, but that was pre-devicetree days.

I expect Tomeu has some better number.. if not I can collect some.

>> Just as an aside, the amount of probe-defer adds quite a lot of noise
>> when you are trying to debug why some driver doesn't probe
>> successfully.  Which itself would be a nice reason to do something
>> more clever..
>
> People seem to not like the noise, so let's turn off those messages,
> that should speed things up :)

heh, except for when you are trying to debug what is missing
preventing the driver you depend on from probing ;-)

BR,
-R

Re: [GIT PULL] On-demand device probing

[Rob Clark]

On Sat, Oct 17, 2015 at 3:04 PM, Noralf Trønnes <noralf@tronnes.org> wrote:
>
> Den 17.10.2015 20:45, skrev Rob Clark:
>>
>> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>>>
>>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>>>>
>>>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>>>> <gregkh@linuxfoundation.org> wrote:
>>>>>>
>>>>>> I'm guessing the time is a matter of probing and undoing the probes
>>>>>> rather than slow h/w. We could maybe improve things by making sure
>>>>>> drivers move what they defer on to the beginning of probe, but that
>>>>>> seems like a horrible, fragile hack.
>>>>>
>>>>> How can calling probe and failing cause 2 seconds?  How many different
>>>>> probe calls are failing here?  Again, a boot log graph would be great
>>>>> to
>>>>> see as it will show the root cause, not just guessing at this.
>>>>
>>>>
>>>> just fwiw, but when you have a driver that depends on several other
>>>> drivers (which in turn depend on other drivers and so on), the amount
>>>> of probe-defer we end up seeing is pretty comical.  Yeah, there
>>>> probably is some room to optimize by juggling around order drivers do
>>>> things in probe.  But that doesn't solve the fundamental problem with
>>>> the current state, about probe order having no clue about
>>>> dependencies..
>>>
>>> I can imagine it is a lot of iterations, but how long does it really
>>> take?  How many different devices are involved that it takes multiple
>>> loops in order to finally work out the correct order?  Where is the time
>>> delays here, just calling probe() and having it instantly return
>>> shouldn't take all that long.
>>
>> offhand, I think the dependencies go at *least* three levels deep..
>> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
>> get all the way through requesting it's various different
>> regulators/clks/gpios.  I hadn't really paid attention to how many
>> tries the drivers I depend on go through.  (Of those, I take clks from
>> two different clk drivers (which have dependency on a 3rd clk driver),
>> and regulators and gpio's come from at least two places, which in turn
>> have dependencies on clks, etc.)  I don't have really good hard
>> numbers handy (since my observations of this are w/ console over uart
>> which effects timings, and so I see it taking much longer than 2sec)..
>> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
>> me.
>>
>> I can try to get better #'s... I should have my kernel hat on at least
>> some of the time next week.. but the 2sec figure didn't seem
>> unrealistic to me.
>
>
> Are you saying that the total boot time is increased by 2 sec due to
> deferred probing, or that display initialization is happening 2 sec
> after it's first try?
>

The 2sec figure was from Tomeu, but I guess display should be probed
in first pass through list of devices (and ofc deferring the first
time), I'll say "probably both"..

BR,
-R

Re: [GIT PULL] On-demand device probing

[Rob Clark]

On Sat, Oct 17, 2015 at 3:04 PM, Noralf Trønnes <noralf@tronnes.org> wrote:
>
> Den 17.10.2015 20:45, skrev Rob Clark:
>>
>> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>>>
>>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>>>>
>>>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>>>> <gregkh@linuxfoundation.org> wrote:
>>>>>>
>>>>>> I'm guessing the time is a matter of probing and undoing the probes
>>>>>> rather than slow h/w. We could maybe improve things by making sure
>>>>>> drivers move what they defer on to the beginning of probe, but that
>>>>>> seems like a horrible, fragile hack.
>>>>>
>>>>> How can calling probe and failing cause 2 seconds?  How many different
>>>>> probe calls are failing here?  Again, a boot log graph would be great
>>>>> to
>>>>> see as it will show the root cause, not just guessing at this.
>>>>
>>>>
>>>> just fwiw, but when you have a driver that depends on several other
>>>> drivers (which in turn depend on other drivers and so on), the amount
>>>> of probe-defer we end up seeing is pretty comical.  Yeah, there
>>>> probably is some room to optimize by juggling around order drivers do
>>>> things in probe.  But that doesn't solve the fundamental problem with
>>>> the current state, about probe order having no clue about
>>>> dependencies..
>>>
>>> I can imagine it is a lot of iterations, but how long does it really
>>> take?  How many different devices are involved that it takes multiple
>>> loops in order to finally work out the correct order?  Where is the time
>>> delays here, just calling probe() and having it instantly return
>>> shouldn't take all that long.
>>
>> offhand, I think the dependencies go at *least* three levels deep..
>> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
>> get all the way through requesting it's various different
>> regulators/clks/gpios.  I hadn't really paid attention to how many
>> tries the drivers I depend on go through.  (Of those, I take clks from
>> two different clk drivers (which have dependency on a 3rd clk driver),
>> and regulators and gpio's come from at least two places, which in turn
>> have dependencies on clks, etc.)  I don't have really good hard
>> numbers handy (since my observations of this are w/ console over uart
>> which effects timings, and so I see it taking much longer than 2sec)..
>> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
>> me.
>>
>> I can try to get better #'s... I should have my kernel hat on at least
>> some of the time next week.. but the 2sec figure didn't seem
>> unrealistic to me.
>
>
> Are you saying that the total boot time is increased by 2 sec due to
> deferred probing, or that display initialization is happening 2 sec
> after it's first try?
>

The 2sec figure was from Tomeu, but I guess display should be probed
in first pass through list of devices (and ofc deferring the first
time), I'll say "probably both"..

BR,
-R

Re: [GIT PULL] On-demand device probing

[Rob Clark]

On Sat, Oct 17, 2015 at 3:04 PM, Noralf Tr=C3=B8nnes <noralf@tronnes.org> w=
rote:
>
> Den 17.10.2015 20:45, skrev Rob Clark:
>>
>> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>>>
>>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>>>>
>>>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>>>> <gregkh@linuxfoundation.org> wrote:
>>>>>>
>>>>>> I'm guessing the time is a matter of probing and undoing the probes
>>>>>> rather than slow h/w. We could maybe improve things by making sure
>>>>>> drivers move what they defer on to the beginning of probe, but that
>>>>>> seems like a horrible, fragile hack.
>>>>>
>>>>> How can calling probe and failing cause 2 seconds?  How many differen=
t
>>>>> probe calls are failing here?  Again, a boot log graph would be great
>>>>> to
>>>>> see as it will show the root cause, not just guessing at this.
>>>>
>>>>
>>>> just fwiw, but when you have a driver that depends on several other
>>>> drivers (which in turn depend on other drivers and so on), the amount
>>>> of probe-defer we end up seeing is pretty comical.  Yeah, there
>>>> probably is some room to optimize by juggling around order drivers do
>>>> things in probe.  But that doesn't solve the fundamental problem with
>>>> the current state, about probe order having no clue about
>>>> dependencies..
>>>
>>> I can imagine it is a lot of iterations, but how long does it really
>>> take?  How many different devices are involved that it takes multiple
>>> loops in order to finally work out the correct order?  Where is the tim=
e
>>> delays here, just calling probe() and having it instantly return
>>> shouldn't take all that long.
>>
>> offhand, I think the dependencies go at *least* three levels deep..
>> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
>> get all the way through requesting it's various different
>> regulators/clks/gpios.  I hadn't really paid attention to how many
>> tries the drivers I depend on go through.  (Of those, I take clks from
>> two different clk drivers (which have dependency on a 3rd clk driver),
>> and regulators and gpio's come from at least two places, which in turn
>> have dependencies on clks, etc.)  I don't have really good hard
>> numbers handy (since my observations of this are w/ console over uart
>> which effects timings, and so I see it taking much longer than 2sec)..
>> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
>> me.
>>
>> I can try to get better #'s... I should have my kernel hat on at least
>> some of the time next week.. but the 2sec figure didn't seem
>> unrealistic to me.
>
>
> Are you saying that the total boot time is increased by 2 sec due to
> deferred probing, or that display initialization is happening 2 sec
> after it's first try?
>

The 2sec figure was from Tomeu, but I guess display should be probed
in first pass through list of devices (and ofc deferring the first
time), I'll say "probably both"..

BR,
-R

Re: [GIT PULL] On-demand device probing

[Rob Clark]

On Sat, Oct 17, 2015 at 3:04 PM, Noralf Trønnes <noralf@tronnes.org> wrote:
>
> Den 17.10.2015 20:45, skrev Rob Clark:
>>
>> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>>>
>>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>>>>
>>>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
>>>> <gregkh@linuxfoundation.org> wrote:
>>>>>>
>>>>>> I'm guessing the time is a matter of probing and undoing the probes
>>>>>> rather than slow h/w. We could maybe improve things by making sure
>>>>>> drivers move what they defer on to the beginning of probe, but that
>>>>>> seems like a horrible, fragile hack.
>>>>>
>>>>> How can calling probe and failing cause 2 seconds?  How many different
>>>>> probe calls are failing here?  Again, a boot log graph would be great
>>>>> to
>>>>> see as it will show the root cause, not just guessing at this.
>>>>
>>>>
>>>> just fwiw, but when you have a driver that depends on several other
>>>> drivers (which in turn depend on other drivers and so on), the amount
>>>> of probe-defer we end up seeing is pretty comical.  Yeah, there
>>>> probably is some room to optimize by juggling around order drivers do
>>>> things in probe.  But that doesn't solve the fundamental problem with
>>>> the current state, about probe order having no clue about
>>>> dependencies..
>>>
>>> I can imagine it is a lot of iterations, but how long does it really
>>> take?  How many different devices are involved that it takes multiple
>>> loops in order to finally work out the correct order?  Where is the time
>>> delays here, just calling probe() and having it instantly return
>>> shouldn't take all that long.
>>
>> offhand, I think the dependencies go at *least* three levels deep..
>> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
>> get all the way through requesting it's various different
>> regulators/clks/gpios.  I hadn't really paid attention to how many
>> tries the drivers I depend on go through.  (Of those, I take clks from
>> two different clk drivers (which have dependency on a 3rd clk driver),
>> and regulators and gpio's come from at least two places, which in turn
>> have dependencies on clks, etc.)  I don't have really good hard
>> numbers handy (since my observations of this are w/ console over uart
>> which effects timings, and so I see it taking much longer than 2sec)..
>> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
>> me.
>>
>> I can try to get better #'s... I should have my kernel hat on at least
>> some of the time next week.. but the 2sec figure didn't seem
>> unrealistic to me.
>
>
> Are you saying that the total boot time is increased by 2 sec due to
> deferred probing, or that display initialization is happening 2 sec
> after it's first try?
>

The 2sec figure was from Tomeu, but I guess display should be probed
in first pass through list of devices (and ofc deferring the first
time), I'll say "probably both"..

BR,
-R

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 03:39:20PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
> >> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> >> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> >> >> <gregkh@linuxfoundation.org> wrote:
> >> >> >> I'm guessing the time is a matter of probing and undoing the probes
> >> >> >> rather than slow h/w. We could maybe improve things by making sure
> >> >> >> drivers move what they defer on to the beginning of probe, but that
> >> >> >> seems like a horrible, fragile hack.
> >> >> >
> >> >> > How can calling probe and failing cause 2 seconds?  How many different
> >> >> > probe calls are failing here?  Again, a boot log graph would be great to
> >> >> > see as it will show the root cause, not just guessing at this.
> >> >>
> >> >>
> >> >> just fwiw, but when you have a driver that depends on several other
> >> >> drivers (which in turn depend on other drivers and so on), the amount
> >> >> of probe-defer we end up seeing is pretty comical.  Yeah, there
> >> >> probably is some room to optimize by juggling around order drivers do
> >> >> things in probe.  But that doesn't solve the fundamental problem with
> >> >> the current state, about probe order having no clue about
> >> >> dependencies..
> >> >
> >> > I can imagine it is a lot of iterations, but how long does it really
> >> > take?  How many different devices are involved that it takes multiple
> >> > loops in order to finally work out the correct order?  Where is the time
> >> > delays here, just calling probe() and having it instantly return
> >> > shouldn't take all that long.
> >>
> >> offhand, I think the dependencies go at *least* three levels deep..
> >> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> >> get all the way through requesting it's various different
> >> regulators/clks/gpios.
> >
> > And how long does that really take?  Numbers please :)
> >
> >> I hadn't really paid attention to how many
> >> tries the drivers I depend on go through.  (Of those, I take clks from
> >> two different clk drivers (which have dependency on a 3rd clk driver),
> >> and regulators and gpio's come from at least two places, which in turn
> >> have dependencies on clks, etc.)  I don't have really good hard
> >> numbers handy (since my observations of this are w/ console over uart
> >> which effects timings, and so I see it taking much longer than 2sec)..
> >> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> >> me.
> >>
> >> I can try to get better #'s... I should have my kernel hat on at least
> >> some of the time next week.. but the 2sec figure didn't seem
> >> unrealistic to me.
> >
> > Based on the time it takes a modern laptop to boot, 2 seconds is
> > forever, there has to be something else going on here other than just
> > calling probe() a bunch of times.  Please use the tools we have to
> > determine this before trying to change the driver core.
> 
> yes, I am aware of the tools.. although so far I spend most of my time
> just trying to get things working in the first place ;-)

And that's where most people stop, if you want to make it fast, you have
to put in more effort, sorry.  Don't expect the driver core to work
around driver bugs for you.

> All I was trying to point out was that Tomeu's figures didn't really
> seem unrealistic.  I mean, given that the average SoC driver probably
> depends on at least one clock and at least one regulator, having to
> probe each driver at least twice seems plausible.  And that having a
> noticeable effect on boot time doesn't seem surprising.  I'm not sure
> that saying 'modern laptop can boot in 2sec' adds much to the
> discussion since I don't think you have quite so much interdependency
> between devices vs random probe order.  I have seen arm devices boot
> to UI in similar times, but that was pre-devicetree days.

2 extra probes add a second to the boot time?  Those sound like really
broken drivers to me :)

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 03:39:20PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
> >> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> >> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> >> >> <gregkh@linuxfoundation.org> wrote:
> >> >> >> I'm guessing the time is a matter of probing and undoing the probes
> >> >> >> rather than slow h/w. We could maybe improve things by making sure
> >> >> >> drivers move what they defer on to the beginning of probe, but that
> >> >> >> seems like a horrible, fragile hack.
> >> >> >
> >> >> > How can calling probe and failing cause 2 seconds?  How many different
> >> >> > probe calls are failing here?  Again, a boot log graph would be great to
> >> >> > see as it will show the root cause, not just guessing at this.
> >> >>
> >> >>
> >> >> just fwiw, but when you have a driver that depends on several other
> >> >> drivers (which in turn depend on other drivers and so on), the amount
> >> >> of probe-defer we end up seeing is pretty comical.  Yeah, there
> >> >> probably is some room to optimize by juggling around order drivers do
> >> >> things in probe.  But that doesn't solve the fundamental problem with
> >> >> the current state, about probe order having no clue about
> >> >> dependencies..
> >> >
> >> > I can imagine it is a lot of iterations, but how long does it really
> >> > take?  How many different devices are involved that it takes multiple
> >> > loops in order to finally work out the correct order?  Where is the time
> >> > delays here, just calling probe() and having it instantly return
> >> > shouldn't take all that long.
> >>
> >> offhand, I think the dependencies go at *least* three levels deep..
> >> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> >> get all the way through requesting it's various different
> >> regulators/clks/gpios.
> >
> > And how long does that really take?  Numbers please :)
> >
> >> I hadn't really paid attention to how many
> >> tries the drivers I depend on go through.  (Of those, I take clks from
> >> two different clk drivers (which have dependency on a 3rd clk driver),
> >> and regulators and gpio's come from at least two places, which in turn
> >> have dependencies on clks, etc.)  I don't have really good hard
> >> numbers handy (since my observations of this are w/ console over uart
> >> which effects timings, and so I see it taking much longer than 2sec)..
> >> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> >> me.
> >>
> >> I can try to get better #'s... I should have my kernel hat on at least
> >> some of the time next week.. but the 2sec figure didn't seem
> >> unrealistic to me.
> >
> > Based on the time it takes a modern laptop to boot, 2 seconds is
> > forever, there has to be something else going on here other than just
> > calling probe() a bunch of times.  Please use the tools we have to
> > determine this before trying to change the driver core.
> 
> yes, I am aware of the tools.. although so far I spend most of my time
> just trying to get things working in the first place ;-)

And that's where most people stop, if you want to make it fast, you have
to put in more effort, sorry.  Don't expect the driver core to work
around driver bugs for you.

> All I was trying to point out was that Tomeu's figures didn't really
> seem unrealistic.  I mean, given that the average SoC driver probably
> depends on at least one clock and at least one regulator, having to
> probe each driver at least twice seems plausible.  And that having a
> noticeable effect on boot time doesn't seem surprising.  I'm not sure
> that saying 'modern laptop can boot in 2sec' adds much to the
> discussion since I don't think you have quite so much interdependency
> between devices vs random probe order.  I have seen arm devices boot
> to UI in similar times, but that was pre-devicetree days.

2 extra probes add a second to the boot time?  Those sound like really
broken drivers to me :)

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sat, Oct 17, 2015 at 03:39:20PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote:
> >> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> >> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> >> >> <gregkh@linuxfoundation.org> wrote:
> >> >> >> I'm guessing the time is a matter of probing and undoing the probes
> >> >> >> rather than slow h/w. We could maybe improve things by making sure
> >> >> >> drivers move what they defer on to the beginning of probe, but that
> >> >> >> seems like a horrible, fragile hack.
> >> >> >
> >> >> > How can calling probe and failing cause 2 seconds?  How many different
> >> >> > probe calls are failing here?  Again, a boot log graph would be great to
> >> >> > see as it will show the root cause, not just guessing at this.
> >> >>
> >> >>
> >> >> just fwiw, but when you have a driver that depends on several other
> >> >> drivers (which in turn depend on other drivers and so on), the amount
> >> >> of probe-defer we end up seeing is pretty comical.  Yeah, there
> >> >> probably is some room to optimize by juggling around order drivers do
> >> >> things in probe.  But that doesn't solve the fundamental problem with
> >> >> the current state, about probe order having no clue about
> >> >> dependencies..
> >> >
> >> > I can imagine it is a lot of iterations, but how long does it really
> >> > take?  How many different devices are involved that it takes multiple
> >> > loops in order to finally work out the correct order?  Where is the time
> >> > delays here, just calling probe() and having it instantly return
> >> > shouldn't take all that long.
> >>
> >> offhand, I think the dependencies go at *least* three levels deep..
> >> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to
> >> get all the way through requesting it's various different
> >> regulators/clks/gpios.
> >
> > And how long does that really take?  Numbers please :)
> >
> >> I hadn't really paid attention to how many
> >> tries the drivers I depend on go through.  (Of those, I take clks from
> >> two different clk drivers (which have dependency on a 3rd clk driver),
> >> and regulators and gpio's come from at least two places, which in turn
> >> have dependencies on clks, etc.)  I don't have really good hard
> >> numbers handy (since my observations of this are w/ console over uart
> >> which effects timings, and so I see it taking much longer than 2sec)..
> >> but the 2sec figure that Tomeu mentioned seemed pretty plausible to
> >> me.
> >>
> >> I can try to get better #'s... I should have my kernel hat on at least
> >> some of the time next week.. but the 2sec figure didn't seem
> >> unrealistic to me.
> >
> > Based on the time it takes a modern laptop to boot, 2 seconds is
> > forever, there has to be something else going on here other than just
> > calling probe() a bunch of times.  Please use the tools we have to
> > determine this before trying to change the driver core.
> 
> yes, I am aware of the tools.. although so far I spend most of my time
> just trying to get things working in the first place ;-)

And that's where most people stop, if you want to make it fast, you have
to put in more effort, sorry.  Don't expect the driver core to work
around driver bugs for you.

> All I was trying to point out was that Tomeu's figures didn't really
> seem unrealistic.  I mean, given that the average SoC driver probably
> depends on at least one clock and at least one regulator, having to
> probe each driver at least twice seems plausible.  And that having a
> noticeable effect on boot time doesn't seem surprising.  I'm not sure
> that saying 'modern laptop can boot in 2sec' adds much to the
> discussion since I don't think you have quite so much interdependency
> between devices vs random probe order.  I have seen arm devices boot
> to UI in similar times, but that was pre-devicetree days.

2 extra probes add a second to the boot time?  Those sound like really
broken drivers to me :)

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]

On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:

> I can't see adding calls like this all over the tree just to solve a
> bus-specific problem, you are adding of_* calls where they aren't
> needed, or wanted, at all.

This isn't bus specific, I'm not sure what makes you say that?

> What is the root-problem of your delay in device probing?  I read your
> last patch series and I can't seem to figure out what the issue is that
> this is solving in any "better" way from the existing deferred probing.

So, I don't actually have any platforms that are especially bothered by
this (at least not for my use cases) so there's a bit of educated
guessing going on here but there's two broad things I'm aware of.  

One is that regardless of the actual performance of the system when
deferred probe goes off it splats errors all over the console which
makes it look like something is going wrong even if everything is fine
in the end.  If lots of deferred probing happens then the volume gets
big too.  People find this distracting, noisy and ugly - it obscures
actual issues and trains people to ignore errors.  I do think this is a
reasonable concern and that it's worth trying to mitigate against
deferral for this reason alone.  We don't want to just ignore the errors
and not print anything either since if the resource doesn't appear the
user needs to know what is preventing the driver from instantiating so
they can try to fix it.

The other is that if you're printing to a serial console then that's not
an especially fast operation so if you're getting lots of messages being
printed simply physically outputting them takes measurable time.  I'm
not aware of any performance concerns outside of that, but like I say
I'm not affected by this myself in any great way.  Obviously this can be
configured but not having actual errors on the console isn't super
awesome either for systems that make use of the logging there and we
don't have a good way of telling what's from deferral and what's not.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]

On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:

> I can't see adding calls like this all over the tree just to solve a
> bus-specific problem, you are adding of_* calls where they aren't
> needed, or wanted, at all.

This isn't bus specific, I'm not sure what makes you say that?

> What is the root-problem of your delay in device probing?  I read your
> last patch series and I can't seem to figure out what the issue is that
> this is solving in any "better" way from the existing deferred probing.

So, I don't actually have any platforms that are especially bothered by
this (at least not for my use cases) so there's a bit of educated
guessing going on here but there's two broad things I'm aware of.  

One is that regardless of the actual performance of the system when
deferred probe goes off it splats errors all over the console which
makes it look like something is going wrong even if everything is fine
in the end.  If lots of deferred probing happens then the volume gets
big too.  People find this distracting, noisy and ugly - it obscures
actual issues and trains people to ignore errors.  I do think this is a
reasonable concern and that it's worth trying to mitigate against
deferral for this reason alone.  We don't want to just ignore the errors
and not print anything either since if the resource doesn't appear the
user needs to know what is preventing the driver from instantiating so
they can try to fix it.

The other is that if you're printing to a serial console then that's not
an especially fast operation so if you're getting lots of messages being
printed simply physically outputting them takes measurable time.  I'm
not aware of any performance concerns outside of that, but like I say
I'm not affected by this myself in any great way.  Obviously this can be
configured but not having actual errors on the console isn't super
awesome either for systems that make use of the logging there and we
don't have a good way of telling what's from deferral and what's not.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]

On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:

> I can't see adding calls like this all over the tree just to solve a
> bus-specific problem, you are adding of_* calls where they aren't
> needed, or wanted, at all.

This isn't bus specific, I'm not sure what makes you say that?

> What is the root-problem of your delay in device probing?  I read your
> last patch series and I can't seem to figure out what the issue is that
> this is solving in any "better" way from the existing deferred probing.

So, I don't actually have any platforms that are especially bothered by
this (at least not for my use cases) so there's a bit of educated
guessing going on here but there's two broad things I'm aware of.  

One is that regardless of the actual performance of the system when
deferred probe goes off it splats errors all over the console which
makes it look like something is going wrong even if everything is fine
in the end.  If lots of deferred probing happens then the volume gets
big too.  People find this distracting, noisy and ugly - it obscures
actual issues and trains people to ignore errors.  I do think this is a
reasonable concern and that it's worth trying to mitigate against
deferral for this reason alone.  We don't want to just ignore the errors
and not print anything either since if the resource doesn't appear the
user needs to know what is preventing the driver from instantiating so
they can try to fix it.

The other is that if you're printing to a serial console then that's not
an especially fast operation so if you're getting lots of messages being
printed simply physically outputting them takes measurable time.  I'm
not aware of any performance concerns outside of that, but like I say
I'm not affected by this myself in any great way.  Obviously this can be
configured but not having actual errors on the console isn't super
awesome either for systems that make use of the logging there and we
don't have a good way of telling what's from deferral and what's not.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> 
> > I can't see adding calls like this all over the tree just to solve a
> > bus-specific problem, you are adding of_* calls where they aren't
> > needed, or wanted, at all.
> 
> This isn't bus specific, I'm not sure what makes you say that?

You are making it bus-specific by putting these calls all over the tree
in different bus subsystems semi-randomly for all I can determine.

> > What is the root-problem of your delay in device probing?  I read your
> > last patch series and I can't seem to figure out what the issue is that
> > this is solving in any "better" way from the existing deferred probing.
> 
> So, I don't actually have any platforms that are especially bothered by
> this (at least not for my use cases) so there's a bit of educated
> guessing going on here but there's two broad things I'm aware of.  
> 
> One is that regardless of the actual performance of the system when
> deferred probe goes off it splats errors all over the console which
> makes it look like something is going wrong even if everything is fine
> in the end.  If lots of deferred probing happens then the volume gets
> big too.  People find this distracting, noisy and ugly - it obscures
> actual issues and trains people to ignore errors.  I do think this is a
> reasonable concern and that it's worth trying to mitigate against
> deferral for this reason alone.  We don't want to just ignore the errors
> and not print anything either since if the resource doesn't appear the
> user needs to know what is preventing the driver from instantiating so
> they can try to fix it.

This has come up many times, I have no objection to just turning that
message into a debug message that can be dynamically enabled for those
people wanting to debug their systems for boot time issues.

Please send a patch to do so.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> 
> > I can't see adding calls like this all over the tree just to solve a
> > bus-specific problem, you are adding of_* calls where they aren't
> > needed, or wanted, at all.
> 
> This isn't bus specific, I'm not sure what makes you say that?

You are making it bus-specific by putting these calls all over the tree
in different bus subsystems semi-randomly for all I can determine.

> > What is the root-problem of your delay in device probing?  I read your
> > last patch series and I can't seem to figure out what the issue is that
> > this is solving in any "better" way from the existing deferred probing.
> 
> So, I don't actually have any platforms that are especially bothered by
> this (at least not for my use cases) so there's a bit of educated
> guessing going on here but there's two broad things I'm aware of.  
> 
> One is that regardless of the actual performance of the system when
> deferred probe goes off it splats errors all over the console which
> makes it look like something is going wrong even if everything is fine
> in the end.  If lots of deferred probing happens then the volume gets
> big too.  People find this distracting, noisy and ugly - it obscures
> actual issues and trains people to ignore errors.  I do think this is a
> reasonable concern and that it's worth trying to mitigate against
> deferral for this reason alone.  We don't want to just ignore the errors
> and not print anything either since if the resource doesn't appear the
> user needs to know what is preventing the driver from instantiating so
> they can try to fix it.

This has come up many times, I have no objection to just turning that
message into a debug message that can be dynamically enabled for those
people wanting to debug their systems for boot time issues.

Please send a patch to do so.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> 
> > I can't see adding calls like this all over the tree just to solve a
> > bus-specific problem, you are adding of_* calls where they aren't
> > needed, or wanted, at all.
> 
> This isn't bus specific, I'm not sure what makes you say that?

You are making it bus-specific by putting these calls all over the tree
in different bus subsystems semi-randomly for all I can determine.

> > What is the root-problem of your delay in device probing?  I read your
> > last patch series and I can't seem to figure out what the issue is that
> > this is solving in any "better" way from the existing deferred probing.
> 
> So, I don't actually have any platforms that are especially bothered by
> this (at least not for my use cases) so there's a bit of educated
> guessing going on here but there's two broad things I'm aware of.  
> 
> One is that regardless of the actual performance of the system when
> deferred probe goes off it splats errors all over the console which
> makes it look like something is going wrong even if everything is fine
> in the end.  If lots of deferred probing happens then the volume gets
> big too.  People find this distracting, noisy and ugly - it obscures
> actual issues and trains people to ignore errors.  I do think this is a
> reasonable concern and that it's worth trying to mitigate against
> deferral for this reason alone.  We don't want to just ignore the errors
> and not print anything either since if the resource doesn't appear the
> user needs to know what is preventing the driver from instantiating so
> they can try to fix it.

This has come up many times, I have no objection to just turning that
message into a debug message that can be dynamically enabled for those
people wanting to debug their systems for boot time issues.

Please send a patch to do so.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

On Sat, Oct 17, 2015 at 08:47:09AM -0700, Greg Kroah-Hartman wrote:
> On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:

> > I think Linus W, Mark B, and I all said a similar thing initially in
> > that dependencies should be handled in the driver core. We went down
> > the path of making this not firmware (aka bus) specific and an earlier
> > version had just that (with fwnode_* calls). That turned out to be
> > pointless as the calling locations were almost always in DT specific
> > code anyway. If you notice, the calls are next to other DT specific
> > calls generally (usually a "get"). So yes, I'd prefer not to have to
> > touch every subsystem, but we had to do that anyway to add DT support.

> If they are "next" to a call like that, why not put it in that call?  I
> really object to having to "sprinkle" this all over the kernel, for no
> obvious reason why that is happening at all (look at the USB patch for
> one such example.)

I did ask that question myself IIRC - we could probably get a long way
by trying to instantiate anything that looks probable when we do a
phandle lookup on it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

On Sat, Oct 17, 2015 at 08:47:09AM -0700, Greg Kroah-Hartman wrote:
> On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:

> > I think Linus W, Mark B, and I all said a similar thing initially in
> > that dependencies should be handled in the driver core. We went down
> > the path of making this not firmware (aka bus) specific and an earlier
> > version had just that (with fwnode_* calls). That turned out to be
> > pointless as the calling locations were almost always in DT specific
> > code anyway. If you notice, the calls are next to other DT specific
> > calls generally (usually a "get"). So yes, I'd prefer not to have to
> > touch every subsystem, but we had to do that anyway to add DT support.

> If they are "next" to a call like that, why not put it in that call?  I
> really object to having to "sprinkle" this all over the kernel, for no
> obvious reason why that is happening at all (look at the USB patch for
> one such example.)

I did ask that question myself IIRC - we could probably get a long way
by trying to instantiate anything that looks probable when we do a
phandle lookup on it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

On Sat, Oct 17, 2015 at 08:47:09AM -0700, Greg Kroah-Hartman wrote:
> On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:

> > I think Linus W, Mark B, and I all said a similar thing initially in
> > that dependencies should be handled in the driver core. We went down
> > the path of making this not firmware (aka bus) specific and an earlier
> > version had just that (with fwnode_* calls). That turned out to be
> > pointless as the calling locations were almost always in DT specific
> > code anyway. If you notice, the calls are next to other DT specific
> > calls generally (usually a "get"). So yes, I'd prefer not to have to
> > touch every subsystem, but we had to do that anyway to add DT support.

> If they are "next" to a call like that, why not put it in that call?  I
> really object to having to "sprinkle" this all over the kernel, for no
> obvious reason why that is happening at all (look at the USB patch for
> one such example.)

I did ask that question myself IIRC - we could probably get a long way
by trying to instantiate anything that looks probable when we do a
phandle lookup on it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]

On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:

> > > I can't see adding calls like this all over the tree just to solve a
> > > bus-specific problem, you are adding of_* calls where they aren't
> > > needed, or wanted, at all.

> > This isn't bus specific, I'm not sure what makes you say that?

> You are making it bus-specific by putting these calls all over the tree
> in different bus subsystems semi-randomly for all I can determine.

Do you mean firmware rather than bus here?  I think that's the confusion
I have...

> > One is that regardless of the actual performance of the system when
> > deferred probe goes off it splats errors all over the console which
> > makes it look like something is going wrong even if everything is fine
> > in the end.  If lots of deferred probing happens then the volume gets
> > big too.  People find this distracting, noisy and ugly - it obscures
> > actual issues and trains people to ignore errors.  I do think this is a
> > reasonable concern and that it's worth trying to mitigate against
> > deferral for this reason alone.  We don't want to just ignore the errors
> > and not print anything either since if the resource doesn't appear the
> > user needs to know what is preventing the driver from instantiating so
> > they can try to fix it.

> This has come up many times, I have no objection to just turning that
> message into a debug message that can be dynamically enabled for those
> people wanting to debug their systems for boot time issues.

It's not just the driver core logging, it's also all the individual
drivers logging that they failed to get whatever resource since silently
failing is not a great user experience.  Many, hopefully most, of the
drivers don't actually have special handling for probe deferral since
half the beauty of probe deferral is that the subsystem supplying the
resource can just return -EPROBE_DEFER when it notices something is
missing but might appear and then the drivers will do the right thing so
long as they have error handling code that they really should have
anyway.

We'd need to have a special dev_err() that handled probe deferral
errors for drivers to use during probe or some other smarts in the
logging infrastructure.  Which isn't a totally horrible idea.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]

On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:

> > > I can't see adding calls like this all over the tree just to solve a
> > > bus-specific problem, you are adding of_* calls where they aren't
> > > needed, or wanted, at all.

> > This isn't bus specific, I'm not sure what makes you say that?

> You are making it bus-specific by putting these calls all over the tree
> in different bus subsystems semi-randomly for all I can determine.

Do you mean firmware rather than bus here?  I think that's the confusion
I have...

> > One is that regardless of the actual performance of the system when
> > deferred probe goes off it splats errors all over the console which
> > makes it look like something is going wrong even if everything is fine
> > in the end.  If lots of deferred probing happens then the volume gets
> > big too.  People find this distracting, noisy and ugly - it obscures
> > actual issues and trains people to ignore errors.  I do think this is a
> > reasonable concern and that it's worth trying to mitigate against
> > deferral for this reason alone.  We don't want to just ignore the errors
> > and not print anything either since if the resource doesn't appear the
> > user needs to know what is preventing the driver from instantiating so
> > they can try to fix it.

> This has come up many times, I have no objection to just turning that
> message into a debug message that can be dynamically enabled for those
> people wanting to debug their systems for boot time issues.

It's not just the driver core logging, it's also all the individual
drivers logging that they failed to get whatever resource since silently
failing is not a great user experience.  Many, hopefully most, of the
drivers don't actually have special handling for probe deferral since
half the beauty of probe deferral is that the subsystem supplying the
resource can just return -EPROBE_DEFER when it notices something is
missing but might appear and then the drivers will do the right thing so
long as they have error handling code that they really should have
anyway.

We'd need to have a special dev_err() that handled probe deferral
errors for drivers to use during probe or some other smarts in the
logging infrastructure.  Which isn't a totally horrible idea.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]

On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:

> > > I can't see adding calls like this all over the tree just to solve a
> > > bus-specific problem, you are adding of_* calls where they aren't
> > > needed, or wanted, at all.

> > This isn't bus specific, I'm not sure what makes you say that?

> You are making it bus-specific by putting these calls all over the tree
> in different bus subsystems semi-randomly for all I can determine.

Do you mean firmware rather than bus here?  I think that's the confusion
I have...

> > One is that regardless of the actual performance of the system when
> > deferred probe goes off it splats errors all over the console which
> > makes it look like something is going wrong even if everything is fine
> > in the end.  If lots of deferred probing happens then the volume gets
> > big too.  People find this distracting, noisy and ugly - it obscures
> > actual issues and trains people to ignore errors.  I do think this is a
> > reasonable concern and that it's worth trying to mitigate against
> > deferral for this reason alone.  We don't want to just ignore the errors
> > and not print anything either since if the resource doesn't appear the
> > user needs to know what is preventing the driver from instantiating so
> > they can try to fix it.

> This has come up many times, I have no objection to just turning that
> message into a debug message that can be dynamically enabled for those
> people wanting to debug their systems for boot time issues.

It's not just the driver core logging, it's also all the individual
drivers logging that they failed to get whatever resource since silently
failing is not a great user experience.  Many, hopefully most, of the
drivers don't actually have special handling for probe deferral since
half the beauty of probe deferral is that the subsystem supplying the
resource can just return -EPROBE_DEFER when it notices something is
missing but might appear and then the drivers will do the right thing so
long as they have error handling code that they really should have
anyway.

We'd need to have a special dev_err() that handled probe deferral
errors for drivers to use during probe or some other smarts in the
logging infrastructure.  Which isn't a totally horrible idea.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> 
> > > > I can't see adding calls like this all over the tree just to solve a
> > > > bus-specific problem, you are adding of_* calls where they aren't
> > > > needed, or wanted, at all.
> 
> > > This isn't bus specific, I'm not sure what makes you say that?
> 
> > You are making it bus-specific by putting these calls all over the tree
> > in different bus subsystems semi-randomly for all I can determine.
> 
> Do you mean firmware rather than bus here?  I think that's the confusion
> I have...

Certainly, if it literally is adding of_* calls then that would seem to
be gratuitously firmware-specific. Nothing should be using those these
days; any new code should be using the generic device property APIs
(except in special cases).

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [GIT PULL] On-demand device probing

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> 
> > > > I can't see adding calls like this all over the tree just to solve a
> > > > bus-specific problem, you are adding of_* calls where they aren't
> > > > needed, or wanted, at all.
> 
> > > This isn't bus specific, I'm not sure what makes you say that?
> 
> > You are making it bus-specific by putting these calls all over the tree
> > in different bus subsystems semi-randomly for all I can determine.
> 
> Do you mean firmware rather than bus here?  I think that's the confusion
> I have...

Certainly, if it literally is adding of_* calls then that would seem to
be gratuitously firmware-specific. Nothing should be using those these
days; any new code should be using the generic device property APIs
(except in special cases).

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [GIT PULL] On-demand device probing

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> 
> > > > I can't see adding calls like this all over the tree just to solve a
> > > > bus-specific problem, you are adding of_* calls where they aren't
> > > > needed, or wanted, at all.
> 
> > > This isn't bus specific, I'm not sure what makes you say that?
> 
> > You are making it bus-specific by putting these calls all over the tree
> > in different bus subsystems semi-randomly for all I can determine.
> 
> Do you mean firmware rather than bus here?  I think that's the confusion
> I have...

Certainly, if it literally is adding of_* calls then that would seem to
be gratuitously firmware-specific. Nothing should be using those these
days; any new code should be using the generic device property APIs
(except in special cases).

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> > On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> > > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> > 
> > > > > I can't see adding calls like this all over the tree just to solve a
> > > > > bus-specific problem, you are adding of_* calls where they aren't
> > > > > needed, or wanted, at all.
> > 
> > > > This isn't bus specific, I'm not sure what makes you say that?
> > 
> > > You are making it bus-specific by putting these calls all over the tree
> > > in different bus subsystems semi-randomly for all I can determine.
> > 
> > Do you mean firmware rather than bus here?  I think that's the confusion
> > I have...
> 
> Certainly, if it literally is adding of_* calls then that would seem to
> be gratuitously firmware-specific. Nothing should be using those these
> days; any new code should be using the generic device property APIs
> (except in special cases).

I asked Linus Walleij about that with the fwnode_get_named_gpiod() stuff,
and Linus didn't seem to know how this should be used.

It doesn't help that dev->fwnode is not initialised, but dev->of_node
is.  Are we supposed to grope around in dev->of_node for the embedded
fwnode instead of using dev->fwnode?

At the moment, at least to me, fwnode looks like some kind of
experimental half-baked thing rather than a real usable solution.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> > On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> > > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> > 
> > > > > I can't see adding calls like this all over the tree just to solve a
> > > > > bus-specific problem, you are adding of_* calls where they aren't
> > > > > needed, or wanted, at all.
> > 
> > > > This isn't bus specific, I'm not sure what makes you say that?
> > 
> > > You are making it bus-specific by putting these calls all over the tree
> > > in different bus subsystems semi-randomly for all I can determine.
> > 
> > Do you mean firmware rather than bus here?  I think that's the confusion
> > I have...
> 
> Certainly, if it literally is adding of_* calls then that would seem to
> be gratuitously firmware-specific. Nothing should be using those these
> days; any new code should be using the generic device property APIs
> (except in special cases).

I asked Linus Walleij about that with the fwnode_get_named_gpiod() stuff,
and Linus didn't seem to know how this should be used.

It doesn't help that dev->fwnode is not initialised, but dev->of_node
is.  Are we supposed to grope around in dev->of_node for the embedded
fwnode instead of using dev->fwnode?

At the moment, at least to me, fwnode looks like some kind of
experimental half-baked thing rather than a real usable solution.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> > On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> > > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> > 
> > > > > I can't see adding calls like this all over the tree just to solve a
> > > > > bus-specific problem, you are adding of_* calls where they aren't
> > > > > needed, or wanted, at all.
> > 
> > > > This isn't bus specific, I'm not sure what makes you say that?
> > 
> > > You are making it bus-specific by putting these calls all over the tree
> > > in different bus subsystems semi-randomly for all I can determine.
> > 
> > Do you mean firmware rather than bus here?  I think that's the confusion
> > I have...
> 
> Certainly, if it literally is adding of_* calls then that would seem to
> be gratuitously firmware-specific. Nothing should be using those these
> days; any new code should be using the generic device property APIs
> (except in special cases).

I asked Linus Walleij about that with the fwnode_get_named_gpiod() stuff,
and Linus didn't seem to know how this should be used.

It doesn't help that dev->fwnode is not initialised, but dev->of_node
is.  Are we supposed to grope around in dev->of_node for the embedded
fwnode instead of using dev->fwnode?

At the moment, at least to me, fwnode looks like some kind of
experimental half-baked thing rather than a real usable solution.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:

> > Do you mean firmware rather than bus here?  I think that's the confusion
> > I have...

> Certainly, if it literally is adding of_* calls then that would seem to
> be gratuitously firmware-specific. Nothing should be using those these
> days; any new code should be using the generic device property APIs
> (except in special cases).

It's not entirely clear to me that we should be moving to fwnode_
wholesale yet - the last advice was to hold off for a little while which
makes sense given that the ACPI community still doesn't seem to have
worked out what it wants to do here and how.  The x86 embedded people
are all gung ho but it's less clear that anyone else wants to use _DSD
in quite the same way (I know of some efforts to use _DSD separately to
the DT compatibility stuff) and there are some vendors who definitely do
have completely different binding schemes for ACPI and DT and therefore
specifically care which is in use.

It would really help if ACPI could get their binding review process in
place, and if we do want to actually start converting everything to
fwnode_ we need to start communicating that actively since otherwise
people can't really be expected to know.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:

> > Do you mean firmware rather than bus here?  I think that's the confusion
> > I have...

> Certainly, if it literally is adding of_* calls then that would seem to
> be gratuitously firmware-specific. Nothing should be using those these
> days; any new code should be using the generic device property APIs
> (except in special cases).

It's not entirely clear to me that we should be moving to fwnode_
wholesale yet - the last advice was to hold off for a little while which
makes sense given that the ACPI community still doesn't seem to have
worked out what it wants to do here and how.  The x86 embedded people
are all gung ho but it's less clear that anyone else wants to use _DSD
in quite the same way (I know of some efforts to use _DSD separately to
the DT compatibility stuff) and there are some vendors who definitely do
have completely different binding schemes for ACPI and DT and therefore
specifically care which is in use.

It would really help if ACPI could get their binding review process in
place, and if we do want to actually start converting everything to
fwnode_ we need to start communicating that actively since otherwise
people can't really be expected to know.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:

> > Do you mean firmware rather than bus here?  I think that's the confusion
> > I have...

> Certainly, if it literally is adding of_* calls then that would seem to
> be gratuitously firmware-specific. Nothing should be using those these
> days; any new code should be using the generic device property APIs
> (except in special cases).

It's not entirely clear to me that we should be moving to fwnode_
wholesale yet - the last advice was to hold off for a little while which
makes sense given that the ACPI community still doesn't seem to have
worked out what it wants to do here and how.  The x86 embedded people
are all gung ho but it's less clear that anyone else wants to use _DSD
in quite the same way (I know of some efforts to use _DSD separately to
the DT compatibility stuff) and there are some vendors who definitely do
have completely different binding schemes for ACPI and DT and therefore
specifically care which is in use.

It would really help if ACPI could get their binding review process in
place, and if we do want to actually start converting everything to
fwnode_ we need to start communicating that actively since otherwise
people can't really be expected to know.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 18 October 2015 at 21:53, Mark Brown <broonie@kernel.org> wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>
>> > > I can't see adding calls like this all over the tree just to solve a
>> > > bus-specific problem, you are adding of_* calls where they aren't
>> > > needed, or wanted, at all.
>
>> > This isn't bus specific, I'm not sure what makes you say that?
>
>> You are making it bus-specific by putting these calls all over the tree
>> in different bus subsystems semi-randomly for all I can determine.
>
> Do you mean firmware rather than bus here?  I think that's the confusion
> I have...

Hi all,

hope you don't mind I summarize the points taken instead of replying
to the individual emails. I tried to address all the concerns that
have been raised again in the cover letter, but I guess I did a bad
job at explaining myself, so here's another (more in-depth) go at it.

1) About the sprinkling of calls, everybody agreed it's a bad smell
from the start, but the intention is to modify the behaviour of the
already-DT-specific part of each subsystem without duplicating code.

A way to avoid the sprinkling would be to move the storage and lookup
of resources to the core (using classes and their list of devices to
replace the likes of __of_usb_find_phy). I also like Mark's idea of
calling of_device_probe from of_parse_phandle, which would be much
less invasive but I'm not sure if it would be right to call that
function in all the current cases in which of_parse_phandle is called.

2) About the goal of the series, what matters to my employer is that
once a device defers its probe it's only going to be reprobed in
late_initcall, after all the devices have been tentatively probed
once. In the practice this means that devices get probed in a
dependency order in which first go devices without dependencies then
go up the tree until the leave devices (which tend to be the ones with
effects visible to the user).

This series changes to another dependency order in which when a leaf
node gets probed, it recursively "pulls" its dependencies. This way we
stop massively delaying the probing of the display devices and vendors
can stop carrying sizeable hacks in their trees which just further
reduce the incentive to upstream.

The above is what funds this work, but in my personal opinion the
biggest advantage of this work is that it makes development on
embedded platforms more efficient because right now we don't have a
way of telling if a device deferred its probe because of an ordering
issue, or because there's a problem. If a device is available and has
a compatible driver, but it cannot be probed because a dependency
isn't going to be available, that's an error and is going to cause
real-world problems unless the device is redundant. Currently we say
nothing because with deferred probe the probe callbacks are also part
of the mechanism that determines the dependency order. I have wasted
countless hours hunting for the reason why a device didn't probe and I
have heard the same several times from others.

Having a specific switch for enabling deferred probe logging sounds
good, but there's going to be hundreds of spurious messages about
deferred probes that were just deferrals and only one of them is going
to be the actual error in which a device failed to find a dependency.

3) Regarding total boot time, I don't expect this series to make much
of a difference because though we would save a lot of matching and
querying for resources, that's little time compared with how long we
wait for hardware to react during probing. Async probing is more
likely to help with drivers that take a long time to probe.

4) About the breakage we have seen, that's not caused so far by
probing devices on-demand but by delaying probes until all built-in
drivers have been registered. The latter isn't strictly needed for
on-demand probing but without it most of the benefits are lost because
probes of dependencies are going to be deferred because the drivers
aren't there yet. We could avoid that by registering drivers also
on-demand but we would need to make the matching information available
beforehand, which is a massive change in itself. This should speed up
boot some, and also cause leaf devices to be up earlier.

One more thing about the breakage we have seen so far is that it's
generally caused by implicit dependencies and hunting those is
probably the second biggest timesink of the linux embedded developer
after failed probes. We depend on hacks such as link order, node order
in the DT, initcall gerrymandering and a blind hope in things that
started some time ago to have finished by now. And those implicit
dependencies are often left completely undocumented. This is really
fragile and breaks often when changing something unrelated such as
when adding another revision of a board or soc and a dependency starts
deferring its probe or is delayed because of something else. Also
breaks with async probing.

Delayed probes can be reverted by disabling a Kconfig, so we can fix
those issues in an ordered manner as time allows (we could disable it
by default now and add CI jobs with that enabled during a transitory
period).

Back when I made the series FW-independent with fwnode additions I
felt in my interaction with the ACPI folks that there's a bit of a
chasm in this issue between embedded and non-embedded people. This
could be because with ACPI most of the low-level hw elements such as
clocks, regulators, gpios and pins are hidden from the kernel and are
already ready when we start probing devices. With DT, the kernel has
to initialize all those and only then it can initialize the higher
level devices that depend on them. This means lots more of devices and
dependencies and thus we feel more acutely the shortcomings of the
current device framework at the scale we are using it today.

I think that having all dependencies be explicit and represented in
the device-driver model, along with a more advanced method of ordering
probes is something that would be good to have at this moment, even if
it won't benefit all users of the kernel.

Thanks,

Tomeu

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 18 October 2015 at 21:53, Mark Brown <broonie@kernel.org> wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>
>> > > I can't see adding calls like this all over the tree just to solve a
>> > > bus-specific problem, you are adding of_* calls where they aren't
>> > > needed, or wanted, at all.
>
>> > This isn't bus specific, I'm not sure what makes you say that?
>
>> You are making it bus-specific by putting these calls all over the tree
>> in different bus subsystems semi-randomly for all I can determine.
>
> Do you mean firmware rather than bus here?  I think that's the confusion
> I have...

Hi all,

hope you don't mind I summarize the points taken instead of replying
to the individual emails. I tried to address all the concerns that
have been raised again in the cover letter, but I guess I did a bad
job at explaining myself, so here's another (more in-depth) go at it.

1) About the sprinkling of calls, everybody agreed it's a bad smell
from the start, but the intention is to modify the behaviour of the
already-DT-specific part of each subsystem without duplicating code.

A way to avoid the sprinkling would be to move the storage and lookup
of resources to the core (using classes and their list of devices to
replace the likes of __of_usb_find_phy). I also like Mark's idea of
calling of_device_probe from of_parse_phandle, which would be much
less invasive but I'm not sure if it would be right to call that
function in all the current cases in which of_parse_phandle is called.

2) About the goal of the series, what matters to my employer is that
once a device defers its probe it's only going to be reprobed in
late_initcall, after all the devices have been tentatively probed
once. In the practice this means that devices get probed in a
dependency order in which first go devices without dependencies then
go up the tree until the leave devices (which tend to be the ones with
effects visible to the user).

This series changes to another dependency order in which when a leaf
node gets probed, it recursively "pulls" its dependencies. This way we
stop massively delaying the probing of the display devices and vendors
can stop carrying sizeable hacks in their trees which just further
reduce the incentive to upstream.

The above is what funds this work, but in my personal opinion the
biggest advantage of this work is that it makes development on
embedded platforms more efficient because right now we don't have a
way of telling if a device deferred its probe because of an ordering
issue, or because there's a problem. If a device is available and has
a compatible driver, but it cannot be probed because a dependency
isn't going to be available, that's an error and is going to cause
real-world problems unless the device is redundant. Currently we say
nothing because with deferred probe the probe callbacks are also part
of the mechanism that determines the dependency order. I have wasted
countless hours hunting for the reason why a device didn't probe and I
have heard the same several times from others.

Having a specific switch for enabling deferred probe logging sounds
good, but there's going to be hundreds of spurious messages about
deferred probes that were just deferrals and only one of them is going
to be the actual error in which a device failed to find a dependency.

3) Regarding total boot time, I don't expect this series to make much
of a difference because though we would save a lot of matching and
querying for resources, that's little time compared with how long we
wait for hardware to react during probing. Async probing is more
likely to help with drivers that take a long time to probe.

4) About the breakage we have seen, that's not caused so far by
probing devices on-demand but by delaying probes until all built-in
drivers have been registered. The latter isn't strictly needed for
on-demand probing but without it most of the benefits are lost because
probes of dependencies are going to be deferred because the drivers
aren't there yet. We could avoid that by registering drivers also
on-demand but we would need to make the matching information available
beforehand, which is a massive change in itself. This should speed up
boot some, and also cause leaf devices to be up earlier.

One more thing about the breakage we have seen so far is that it's
generally caused by implicit dependencies and hunting those is
probably the second biggest timesink of the linux embedded developer
after failed probes. We depend on hacks such as link order, node order
in the DT, initcall gerrymandering and a blind hope in things that
started some time ago to have finished by now. And those implicit
dependencies are often left completely undocumented. This is really
fragile and breaks often when changing something unrelated such as
when adding another revision of a board or soc and a dependency starts
deferring its probe or is delayed because of something else. Also
breaks with async probing.

Delayed probes can be reverted by disabling a Kconfig, so we can fix
those issues in an ordered manner as time allows (we could disable it
by default now and add CI jobs with that enabled during a transitory
period).

Back when I made the series FW-independent with fwnode additions I
felt in my interaction with the ACPI folks that there's a bit of a
chasm in this issue between embedded and non-embedded people. This
could be because with ACPI most of the low-level hw elements such as
clocks, regulators, gpios and pins are hidden from the kernel and are
already ready when we start probing devices. With DT, the kernel has
to initialize all those and only then it can initialize the higher
level devices that depend on them. This means lots more of devices and
dependencies and thus we feel more acutely the shortcomings of the
current device framework at the scale we are using it today.

I think that having all dependencies be explicit and represented in
the device-driver model, along with a more advanced method of ordering
probes is something that would be good to have at this moment, even if
it won't benefit all users of the kernel.

Thanks,

Tomeu

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 18 October 2015 at 21:53, Mark Brown <broonie@kernel.org> wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>
>> > > I can't see adding calls like this all over the tree just to solve a
>> > > bus-specific problem, you are adding of_* calls where they aren't
>> > > needed, or wanted, at all.
>
>> > This isn't bus specific, I'm not sure what makes you say that?
>
>> You are making it bus-specific by putting these calls all over the tree
>> in different bus subsystems semi-randomly for all I can determine.
>
> Do you mean firmware rather than bus here?  I think that's the confusion
> I have...

Hi all,

hope you don't mind I summarize the points taken instead of replying
to the individual emails. I tried to address all the concerns that
have been raised again in the cover letter, but I guess I did a bad
job at explaining myself, so here's another (more in-depth) go at it.

1) About the sprinkling of calls, everybody agreed it's a bad smell
from the start, but the intention is to modify the behaviour of the
already-DT-specific part of each subsystem without duplicating code.

A way to avoid the sprinkling would be to move the storage and lookup
of resources to the core (using classes and their list of devices to
replace the likes of __of_usb_find_phy). I also like Mark's idea of
calling of_device_probe from of_parse_phandle, which would be much
less invasive but I'm not sure if it would be right to call that
function in all the current cases in which of_parse_phandle is called.

2) About the goal of the series, what matters to my employer is that
once a device defers its probe it's only going to be reprobed in
late_initcall, after all the devices have been tentatively probed
once. In the practice this means that devices get probed in a
dependency order in which first go devices without dependencies then
go up the tree until the leave devices (which tend to be the ones with
effects visible to the user).

This series changes to another dependency order in which when a leaf
node gets probed, it recursively "pulls" its dependencies. This way we
stop massively delaying the probing of the display devices and vendors
can stop carrying sizeable hacks in their trees which just further
reduce the incentive to upstream.

The above is what funds this work, but in my personal opinion the
biggest advantage of this work is that it makes development on
embedded platforms more efficient because right now we don't have a
way of telling if a device deferred its probe because of an ordering
issue, or because there's a problem. If a device is available and has
a compatible driver, but it cannot be probed because a dependency
isn't going to be available, that's an error and is going to cause
real-world problems unless the device is redundant. Currently we say
nothing because with deferred probe the probe callbacks are also part
of the mechanism that determines the dependency order. I have wasted
countless hours hunting for the reason why a device didn't probe and I
have heard the same several times from others.

Having a specific switch for enabling deferred probe logging sounds
good, but there's going to be hundreds of spurious messages about
deferred probes that were just deferrals and only one of them is going
to be the actual error in which a device failed to find a dependency.

3) Regarding total boot time, I don't expect this series to make much
of a difference because though we would save a lot of matching and
querying for resources, that's little time compared with how long we
wait for hardware to react during probing. Async probing is more
likely to help with drivers that take a long time to probe.

4) About the breakage we have seen, that's not caused so far by
probing devices on-demand but by delaying probes until all built-in
drivers have been registered. The latter isn't strictly needed for
on-demand probing but without it most of the benefits are lost because
probes of dependencies are going to be deferred because the drivers
aren't there yet. We could avoid that by registering drivers also
on-demand but we would need to make the matching information available
beforehand, which is a massive change in itself. This should speed up
boot some, and also cause leaf devices to be up earlier.

One more thing about the breakage we have seen so far is that it's
generally caused by implicit dependencies and hunting those is
probably the second biggest timesink of the linux embedded developer
after failed probes. We depend on hacks such as link order, node order
in the DT, initcall gerrymandering and a blind hope in things that
started some time ago to have finished by now. And those implicit
dependencies are often left completely undocumented. This is really
fragile and breaks often when changing something unrelated such as
when adding another revision of a board or soc and a dependency starts
deferring its probe or is delayed because of something else. Also
breaks with async probing.

Delayed probes can be reverted by disabling a Kconfig, so we can fix
those issues in an ordered manner as time allows (we could disable it
by default now and add CI jobs with that enabled during a transitory
period).

Back when I made the series FW-independent with fwnode additions I
felt in my interaction with the ACPI folks that there's a bit of a
chasm in this issue between embedded and non-embedded people. This
could be because with ACPI most of the low-level hw elements such as
clocks, regulators, gpios and pins are hidden from the kernel and are
already ready when we start probing devices. With DT, the kernel has
to initialize all those and only then it can initialize the higher
level devices that depend on them. This means lots more of devices and
dependencies and thus we feel more acutely the shortcomings of the
current device framework at the scale we are using it today.

I think that having all dependencies be explicit and represented in
the device-driver model, along with a more advanced method of ordering
probes is something that would be good to have at this moment, even if
it won't benefit all users of the kernel.

Thanks,

Tomeu

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Mon, Oct 19, 2015 at 4:44 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
>> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>> > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>> > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>>
>> > > > I can't see adding calls like this all over the tree just to solve a
>> > > > bus-specific problem, you are adding of_* calls where they aren't
>> > > > needed, or wanted, at all.
>>
>> > > This isn't bus specific, I'm not sure what makes you say that?
>>
>> > You are making it bus-specific by putting these calls all over the tree
>> > in different bus subsystems semi-randomly for all I can determine.
>>
>> Do you mean firmware rather than bus here?  I think that's the confusion
>> I have...
>
> Certainly, if it literally is adding of_* calls then that would seem to
> be gratuitously firmware-specific. Nothing should be using those these
> days; any new code should be using the generic device property APIs
> (except in special cases).

See version 2 of the series[1] which did that. It became obvious that
was pointless because the call paths ended up looking like this:

Generic subsystem code -> DT look-up code -> fwnode_probe_device ->
of_probe_device

Rob

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/361137.html

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Mon, Oct 19, 2015 at 4:44 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
>> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>> > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>> > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>>
>> > > > I can't see adding calls like this all over the tree just to solve a
>> > > > bus-specific problem, you are adding of_* calls where they aren't
>> > > > needed, or wanted, at all.
>>
>> > > This isn't bus specific, I'm not sure what makes you say that?
>>
>> > You are making it bus-specific by putting these calls all over the tree
>> > in different bus subsystems semi-randomly for all I can determine.
>>
>> Do you mean firmware rather than bus here?  I think that's the confusion
>> I have...
>
> Certainly, if it literally is adding of_* calls then that would seem to
> be gratuitously firmware-specific. Nothing should be using those these
> days; any new code should be using the generic device property APIs
> (except in special cases).

See version 2 of the series[1] which did that. It became obvious that
was pointless because the call paths ended up looking like this:

Generic subsystem code -> DT look-up code -> fwnode_probe_device ->
of_probe_device

Rob

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/361137.html

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Mon, Oct 19, 2015 at 4:44 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
>> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>> > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>> > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>>
>> > > > I can't see adding calls like this all over the tree just to solve a
>> > > > bus-specific problem, you are adding of_* calls where they aren't
>> > > > needed, or wanted, at all.
>>
>> > > This isn't bus specific, I'm not sure what makes you say that?
>>
>> > You are making it bus-specific by putting these calls all over the tree
>> > in different bus subsystems semi-randomly for all I can determine.
>>
>> Do you mean firmware rather than bus here?  I think that's the confusion
>> I have...
>
> Certainly, if it literally is adding of_* calls then that would seem to
> be gratuitously firmware-specific. Nothing should be using those these
> days; any new code should be using the generic device property APIs
> (except in special cases).

See version 2 of the series[1] which did that. It became obvious that
was pointless because the call paths ended up looking like this:

Generic subsystem code -> DT look-up code -> fwnode_probe_device ->
of_probe_device

Rob

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/361137.html

Re: [GIT PULL] On-demand device probing

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:
> 
> > Certainly, if it literally is adding of_* calls then that would seem to
> > be gratuitously firmware-specific. Nothing should be using those these
> > days; any new code should be using the generic device property APIs
> > (except in special cases).
> 
> See version 2 of the series[1] which did that. It became obvious that
> was pointless because the call paths ended up looking like this:
> 
> Generic subsystem code -> DT look-up code -> fwnode_probe_device ->
> of_probe_device

You link to a thread which says that "AT LEAST CURRENTLY, the calling
locations [the 'DT look-up code' you mention above] are DT specific
functions anyway.

But the point I'm making is that we are working towards *fixing* that,
and *not* using DT-specific code in places where we should be using the
generic APIs.

Sure, Russell is probably right that there are some places where the
generic APIs need fixing because they don't quite cover all use cases
yet.

And Mark is (unfortunately) right that some people are inventing new
bindings *purely* for ACPI which are different to the DT bindings for
the same device. But still, in those cases you'll theoretically be able
to see the *same* device represented under ACPI with *either* its new
ACPI HID and the ACPI-specific bindings, *or* as a PRP0001 with the DT
bindings. And this was always possible even with just DT — you could
have two incompatible bindings for the *same* hardware, with different
drivers. It was just a bad thing. And still is when one is ACPI and one
is DT, in my opinion.

None of that really negates that fact that we are *working* on cleaning
these code paths up to be firmware-agnostic, and the fact that we
haven't got to this one *yet* isn't necessarily a good reason to make
it *worse* by adding new firmware-specificity to it.

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [GIT PULL] On-demand device probing

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:
> 
> > Certainly, if it literally is adding of_* calls then that would seem to
> > be gratuitously firmware-specific. Nothing should be using those these
> > days; any new code should be using the generic device property APIs
> > (except in special cases).
> 
> See version 2 of the series[1] which did that. It became obvious that
> was pointless because the call paths ended up looking like this:
> 
> Generic subsystem code -> DT look-up code -> fwnode_probe_device ->
> of_probe_device

You link to a thread which says that "AT LEAST CURRENTLY, the calling
locations [the 'DT look-up code' you mention above] are DT specific
functions anyway.

But the point I'm making is that we are working towards *fixing* that,
and *not* using DT-specific code in places where we should be using the
generic APIs.

Sure, Russell is probably right that there are some places where the
generic APIs need fixing because they don't quite cover all use cases
yet.

And Mark is (unfortunately) right that some people are inventing new
bindings *purely* for ACPI which are different to the DT bindings for
the same device. But still, in those cases you'll theoretically be able
to see the *same* device represented under ACPI with *either* its new
ACPI HID and the ACPI-specific bindings, *or* as a PRP0001 with the DT
bindings. And this was always possible even with just DT — you could
have two incompatible bindings for the *same* hardware, with different
drivers. It was just a bad thing. And still is when one is ACPI and one
is DT, in my opinion.

None of that really negates that fact that we are *working* on cleaning
these code paths up to be firmware-agnostic, and the fact that we
haven't got to this one *yet* isn't necessarily a good reason to make
it *worse* by adding new firmware-specificity to it.

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [GIT PULL] On-demand device probing

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:
> 
> > Certainly, if it literally is adding of_* calls then that would seem to
> > be gratuitously firmware-specific. Nothing should be using those these
> > days; any new code should be using the generic device property APIs
> > (except in special cases).
> 
> See version 2 of the series[1] which did that. It became obvious that
> was pointless because the call paths ended up looking like this:
> 
> Generic subsystem code -> DT look-up code -> fwnode_probe_device ->
> of_probe_device

You link to a thread which says that "AT LEAST CURRENTLY, the calling
locations [the 'DT look-up code' you mention above] are DT specific
functions anyway.

But the point I'm making is that we are working towards *fixing* that,
and *not* using DT-specific code in places where we should be using the
generic APIs.

Sure, Russell is probably right that there are some places where the
generic APIs need fixing because they don't quite cover all use cases
yet.

And Mark is (unfortunately) right that some people are inventing new
bindings *purely* for ACPI which are different to the DT bindings for
the same device. But still, in those cases you'll theoretically be able
to see the *same* device represented under ACPI with *either* its new
ACPI HID and the ACPI-specific bindings, *or* as a PRP0001 with the DT
bindings. And this was always possible even with just DT — you could
have two incompatible bindings for the *same* hardware, with different
drivers. It was just a bad thing. And still is when one is ACPI and one
is DT, in my opinion.

None of that really negates that fact that we are *working* on cleaning
these code paths up to be firmware-agnostic, and the fact that we
haven't got to this one *yet* isn't necessarily a good reason to make
it *worse* by adding new firmware-specificity to it.

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
> ... If a device is available and has
> a compatible driver, but it cannot be probed because a dependency
> isn't going to be available, that's an error and is going to cause
> real-world problems unless the device is redundant. Currently we say
> nothing because with deferred probe the probe callbacks are also part
> of the mechanism that determines the dependency order.

So what if device X depends on device Y, and we have a driver for
device Y built-in to the kernel, but the driver for device X is a
module?

I don't see this being solvable in the way you describe above - it's
going to identify X as being unable to be satisfied, and report it as
an error - but it's not an error at all.

> Having a specific switch for enabling deferred probe logging sounds
> good, but there's going to be hundreds of spurious messages about
> deferred probes that were just deferrals and only one of them is going
> to be the actual error in which a device failed to find a dependency.

Why would there be?  Sounds like something's very wrong there.

You should only get deferred probes for devices which are declared to
be present, but their resources have not yet been satisfied.  It
doesn't change anything if you have a kernel with lots of device drivers
or just the device drivers you need - the device drivers you don't need
do not contribute to the deferred probing in any way.

So, really, after boot and all appropriate modules have been loaded,
you should end up with no deferred probes.  Are you saying that you
still have "hundreds" at that point?  If you do, that sounds like
there's something very wrong.

> 3) Regarding total boot time, I don't expect this series to make much
> of a difference because though we would save a lot of matching and
> querying for resources, that's little time compared with how long we
> wait for hardware to react during probing. Async probing is more
> likely to help with drivers that take a long time to probe.

For me, on my fastest ARM board, though running serial console:

[    2.293468] VFS: Mounted root (ext4 filesystem) on device 179:1.

There's a couple of delays in there, but they're not down to deferred
probing.  The biggest one is serial console startup (due to the time
it takes to write out the initial kernel messages):

[    0.289962] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 23, base_baud = 15625000) is a 16550A
[    0.944124] console [ttyS0] enabled

and DSA switch initialisation:

[    1.530655] libphy: dsa slave smi: probed
[    2.034426] dsa dsa@0 lan6 (uninitialized): attached PHY at address 0 [Generic PHY]

I'm not sure what causes that, but at a guess it's having to talk to the
DSA switch over the MDIO bus via several layers of indirect accesses.
Of course, serial console adds to the boot time significantly anyway,
especially at the "standard" kernel logging level.

> One more thing about the breakage we have seen so far is that it's
> generally caused by implicit dependencies and hunting those is
> probably the second biggest timesink of the linux embedded developer
> after failed probes.

... which is generally caused by the crappy code which the average
embedded Linux developer creates, particularly with the crappy error
messages they like creating.  For the most part, they _might_ as well
just print "Error!\n" and be done with it, for all the use they are.
When creating an error print, your average embedded Linux developer
fails to print the _reason_ why something failed, which makes debugging
it much harder.

The first thing I do when I touch code that needs this kind of debugging
is to go through and add printing of the error code.  That normally lets
me quickly narrow down what's failed.

If embedded Linux developers are struggling with this, they only have
themselves to blame.

In the case of deferred probing, what _may_ help is if we got rid of the
core code printing that driver X requested deferred probing, instead
moving the responsibility to report this onto the driver or subsystem.
Resource claiming generally has the struct device, and can use dev_warn()
to report which device is being probed, along with which resource is
not yet available.

This debug problem is solvable without needing to resort to complex
probing solutions.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
> ... If a device is available and has
> a compatible driver, but it cannot be probed because a dependency
> isn't going to be available, that's an error and is going to cause
> real-world problems unless the device is redundant. Currently we say
> nothing because with deferred probe the probe callbacks are also part
> of the mechanism that determines the dependency order.

So what if device X depends on device Y, and we have a driver for
device Y built-in to the kernel, but the driver for device X is a
module?

I don't see this being solvable in the way you describe above - it's
going to identify X as being unable to be satisfied, and report it as
an error - but it's not an error at all.

> Having a specific switch for enabling deferred probe logging sounds
> good, but there's going to be hundreds of spurious messages about
> deferred probes that were just deferrals and only one of them is going
> to be the actual error in which a device failed to find a dependency.

Why would there be?  Sounds like something's very wrong there.

You should only get deferred probes for devices which are declared to
be present, but their resources have not yet been satisfied.  It
doesn't change anything if you have a kernel with lots of device drivers
or just the device drivers you need - the device drivers you don't need
do not contribute to the deferred probing in any way.

So, really, after boot and all appropriate modules have been loaded,
you should end up with no deferred probes.  Are you saying that you
still have "hundreds" at that point?  If you do, that sounds like
there's something very wrong.

> 3) Regarding total boot time, I don't expect this series to make much
> of a difference because though we would save a lot of matching and
> querying for resources, that's little time compared with how long we
> wait for hardware to react during probing. Async probing is more
> likely to help with drivers that take a long time to probe.

For me, on my fastest ARM board, though running serial console:

[    2.293468] VFS: Mounted root (ext4 filesystem) on device 179:1.

There's a couple of delays in there, but they're not down to deferred
probing.  The biggest one is serial console startup (due to the time
it takes to write out the initial kernel messages):

[    0.289962] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 23, base_baud = 15625000) is a 16550A
[    0.944124] console [ttyS0] enabled

and DSA switch initialisation:

[    1.530655] libphy: dsa slave smi: probed
[    2.034426] dsa dsa@0 lan6 (uninitialized): attached PHY at address 0 [Generic PHY]

I'm not sure what causes that, but at a guess it's having to talk to the
DSA switch over the MDIO bus via several layers of indirect accesses.
Of course, serial console adds to the boot time significantly anyway,
especially at the "standard" kernel logging level.

> One more thing about the breakage we have seen so far is that it's
> generally caused by implicit dependencies and hunting those is
> probably the second biggest timesink of the linux embedded developer
> after failed probes.

... which is generally caused by the crappy code which the average
embedded Linux developer creates, particularly with the crappy error
messages they like creating.  For the most part, they _might_ as well
just print "Error!\n" and be done with it, for all the use they are.
When creating an error print, your average embedded Linux developer
fails to print the _reason_ why something failed, which makes debugging
it much harder.

The first thing I do when I touch code that needs this kind of debugging
is to go through and add printing of the error code.  That normally lets
me quickly narrow down what's failed.

If embedded Linux developers are struggling with this, they only have
themselves to blame.

In the case of deferred probing, what _may_ help is if we got rid of the
core code printing that driver X requested deferred probing, instead
moving the responsibility to report this onto the driver or subsystem.
Resource claiming generally has the struct device, and can use dev_warn()
to report which device is being probed, along with which resource is
not yet available.

This debug problem is solvable without needing to resort to complex
probing solutions.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
> ... If a device is available and has
> a compatible driver, but it cannot be probed because a dependency
> isn't going to be available, that's an error and is going to cause
> real-world problems unless the device is redundant. Currently we say
> nothing because with deferred probe the probe callbacks are also part
> of the mechanism that determines the dependency order.

So what if device X depends on device Y, and we have a driver for
device Y built-in to the kernel, but the driver for device X is a
module?

I don't see this being solvable in the way you describe above - it's
going to identify X as being unable to be satisfied, and report it as
an error - but it's not an error at all.

> Having a specific switch for enabling deferred probe logging sounds
> good, but there's going to be hundreds of spurious messages about
> deferred probes that were just deferrals and only one of them is going
> to be the actual error in which a device failed to find a dependency.

Why would there be?  Sounds like something's very wrong there.

You should only get deferred probes for devices which are declared to
be present, but their resources have not yet been satisfied.  It
doesn't change anything if you have a kernel with lots of device drivers
or just the device drivers you need - the device drivers you don't need
do not contribute to the deferred probing in any way.

So, really, after boot and all appropriate modules have been loaded,
you should end up with no deferred probes.  Are you saying that you
still have "hundreds" at that point?  If you do, that sounds like
there's something very wrong.

> 3) Regarding total boot time, I don't expect this series to make much
> of a difference because though we would save a lot of matching and
> querying for resources, that's little time compared with how long we
> wait for hardware to react during probing. Async probing is more
> likely to help with drivers that take a long time to probe.

For me, on my fastest ARM board, though running serial console:

[    2.293468] VFS: Mounted root (ext4 filesystem) on device 179:1.

There's a couple of delays in there, but they're not down to deferred
probing.  The biggest one is serial console startup (due to the time
it takes to write out the initial kernel messages):

[    0.289962] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 23, base_baud = 15625000) is a 16550A
[    0.944124] console [ttyS0] enabled

and DSA switch initialisation:

[    1.530655] libphy: dsa slave smi: probed
[    2.034426] dsa dsa@0 lan6 (uninitialized): attached PHY at address 0 [Generic PHY]

I'm not sure what causes that, but at a guess it's having to talk to the
DSA switch over the MDIO bus via several layers of indirect accesses.
Of course, serial console adds to the boot time significantly anyway,
especially at the "standard" kernel logging level.

> One more thing about the breakage we have seen so far is that it's
> generally caused by implicit dependencies and hunting those is
> probably the second biggest timesink of the linux embedded developer
> after failed probes.

... which is generally caused by the crappy code which the average
embedded Linux developer creates, particularly with the crappy error
messages they like creating.  For the most part, they _might_ as well
just print "Error!\n" and be done with it, for all the use they are.
When creating an error print, your average embedded Linux developer
fails to print the _reason_ why something failed, which makes debugging
it much harder.

The first thing I do when I touch code that needs this kind of debugging
is to go through and add printing of the error code.  That normally lets
me quickly narrow down what's failed.

If embedded Linux developers are struggling with this, they only have
themselves to blame.

In the case of deferred probing, what _may_ help is if we got rid of the
core code printing that driver X requested deferred probing, instead
moving the responsibility to report this onto the driver or subsystem.
Resource claiming generally has the struct device, and can use dev_warn()
to report which device is being probed, along with which resource is
not yet available.

This debug problem is solvable without needing to resort to complex
probing solutions.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 19 October 2015 at 15:18, Russell King - ARM Linux
<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> ... If a device is available and has
>> a compatible driver, but it cannot be probed because a dependency
>> isn't going to be available, that's an error and is going to cause
>> real-world problems unless the device is redundant. Currently we say
>> nothing because with deferred probe the probe callbacks are also part
>> of the mechanism that determines the dependency order.
>
> So what if device X depends on device Y, and we have a driver for
> device Y built-in to the kernel, but the driver for device X is a
> module?
>
> I don't see this being solvable in the way you describe above - it's
> going to identify X as being unable to be satisfied, and report it as
> an error - but it's not an error at all.

It's going to probe Y at late_initcall, then probe X when its driver
is registered. No deferred probes nor messages about it.

But if you meant to write the opposite case (X built-in and Y in a
module), then I have to ask you in what situation that would make
sense.

>> Having a specific switch for enabling deferred probe logging sounds
>> good, but there's going to be hundreds of spurious messages about
>> deferred probes that were just deferrals and only one of them is going
>> to be the actual error in which a device failed to find a dependency.
>
> Why would there be?  Sounds like something's very wrong there.

Sorry about that, I have checked that only now and I "only" get 39
deferred probe messages on exynos5250-snow.

> You should only get deferred probes for devices which are declared to
> be present, but their resources have not yet been satisfied.  It
> doesn't change anything if you have a kernel with lots of device drivers
> or just the device drivers you need - the device drivers you don't need
> do not contribute to the deferred probing in any way.

I don't think that the number of registered drivers affects the number
of probes that get deferred (but I'm not sure why you mention that).

> So, really, after boot and all appropriate modules have been loaded,
> you should end up with no deferred probes.  Are you saying that you
> still have "hundreds" at that point?  If you do, that sounds like
> there's something very wrong.

I was talking about messages if we log each -EPROBE_DEFER, not devices
that remain to be probed. The point being that right now we don't have
a way to know if we are deferring because the dependency will be
around later, or if we have a problem and the dependency isn't going
to be there at all.

If we had a way to enable printing the cause of each -EPROBE_DEFER,
right now that would print 39 messages of this board that are only due
to ordering. The actual issue would be printed in exactly the same way
somewhere in the middle.

>> 3) Regarding total boot time, I don't expect this series to make much
>> of a difference because though we would save a lot of matching and
>> querying for resources, that's little time compared with how long we
>> wait for hardware to react during probing. Async probing is more
>> likely to help with drivers that take a long time to probe.
>
> For me, on my fastest ARM board, though running serial console:
>
> [    2.293468] VFS: Mounted root (ext4 filesystem) on device 179:1.
>
> There's a couple of delays in there, but they're not down to deferred
> probing.  The biggest one is serial console startup (due to the time
> it takes to write out the initial kernel messages):
>
> [    0.289962] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 23, base_baud = 15625000) is a 16550A
> [    0.944124] console [ttyS0] enabled
>
> and DSA switch initialisation:
>
> [    1.530655] libphy: dsa slave smi: probed
> [    2.034426] dsa dsa@0 lan6 (uninitialized): attached PHY at address 0 [Generic PHY]
>
> I'm not sure what causes that, but at a guess it's having to talk to the
> DSA switch over the MDIO bus via several layers of indirect accesses.
> Of course, serial console adds to the boot time significantly anyway,
> especially at the "standard" kernel logging level.

Yes, I don't think it makes any sense to measure boot times with the
serial console on, because it's not comparable to production and
because printing an additional line during boot affects significantly
the times.

To be clear, I was saying that this series should NOT affect total
boot times much.

>> One more thing about the breakage we have seen so far is that it's
>> generally caused by implicit dependencies and hunting those is
>> probably the second biggest timesink of the linux embedded developer
>> after failed probes.
>
> ... which is generally caused by the crappy code which the average
> embedded Linux developer creates, particularly with the crappy error
> messages they like creating.  For the most part, they _might_ as well
> just print "Error!\n" and be done with it, for all the use they are.
> When creating an error print, your average embedded Linux developer
> fails to print the _reason_ why something failed, which makes debugging
> it much harder.
>
> The first thing I do when I touch code that needs this kind of debugging
> is to go through and add printing of the error code.  That normally lets
> me quickly narrow down what's failed.
>
> If embedded Linux developers are struggling with this, they only have
> themselves to blame.
>
> In the case of deferred probing, what _may_ help is if we got rid of the
> core code printing that driver X requested deferred probing, instead
> moving the responsibility to report this onto the driver or subsystem.
> Resource claiming generally has the struct device, and can use dev_warn()
> to report which device is being probed, along with which resource is
> not yet available.

Agreed, with the note from above on why it would be better to only
print such a message only when the -EPROBE_DEFER is likely to be a
problem.

> This debug problem is solvable without needing to resort to complex
> probing solutions.

If you really think anything in this series is complex, you should
look at the other ones that tried to accomplish the same!

Thanks,

Tomeu

> --
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 19 October 2015 at 15:18, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> ... If a device is available and has
>> a compatible driver, but it cannot be probed because a dependency
>> isn't going to be available, that's an error and is going to cause
>> real-world problems unless the device is redundant. Currently we say
>> nothing because with deferred probe the probe callbacks are also part
>> of the mechanism that determines the dependency order.
>
> So what if device X depends on device Y, and we have a driver for
> device Y built-in to the kernel, but the driver for device X is a
> module?
>
> I don't see this being solvable in the way you describe above - it's
> going to identify X as being unable to be satisfied, and report it as
> an error - but it's not an error at all.

It's going to probe Y at late_initcall, then probe X when its driver
is registered. No deferred probes nor messages about it.

But if you meant to write the opposite case (X built-in and Y in a
module), then I have to ask you in what situation that would make
sense.

>> Having a specific switch for enabling deferred probe logging sounds
>> good, but there's going to be hundreds of spurious messages about
>> deferred probes that were just deferrals and only one of them is going
>> to be the actual error in which a device failed to find a dependency.
>
> Why would there be?  Sounds like something's very wrong there.

Sorry about that, I have checked that only now and I "only" get 39
deferred probe messages on exynos5250-snow.

> You should only get deferred probes for devices which are declared to
> be present, but their resources have not yet been satisfied.  It
> doesn't change anything if you have a kernel with lots of device drivers
> or just the device drivers you need - the device drivers you don't need
> do not contribute to the deferred probing in any way.

I don't think that the number of registered drivers affects the number
of probes that get deferred (but I'm not sure why you mention that).

> So, really, after boot and all appropriate modules have been loaded,
> you should end up with no deferred probes.  Are you saying that you
> still have "hundreds" at that point?  If you do, that sounds like
> there's something very wrong.

I was talking about messages if we log each -EPROBE_DEFER, not devices
that remain to be probed. The point being that right now we don't have
a way to know if we are deferring because the dependency will be
around later, or if we have a problem and the dependency isn't going
to be there at all.

If we had a way to enable printing the cause of each -EPROBE_DEFER,
right now that would print 39 messages of this board that are only due
to ordering. The actual issue would be printed in exactly the same way
somewhere in the middle.

>> 3) Regarding total boot time, I don't expect this series to make much
>> of a difference because though we would save a lot of matching and
>> querying for resources, that's little time compared with how long we
>> wait for hardware to react during probing. Async probing is more
>> likely to help with drivers that take a long time to probe.
>
> For me, on my fastest ARM board, though running serial console:
>
> [    2.293468] VFS: Mounted root (ext4 filesystem) on device 179:1.
>
> There's a couple of delays in there, but they're not down to deferred
> probing.  The biggest one is serial console startup (due to the time
> it takes to write out the initial kernel messages):
>
> [    0.289962] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 23, base_baud = 15625000) is a 16550A
> [    0.944124] console [ttyS0] enabled
>
> and DSA switch initialisation:
>
> [    1.530655] libphy: dsa slave smi: probed
> [    2.034426] dsa dsa@0 lan6 (uninitialized): attached PHY at address 0 [Generic PHY]
>
> I'm not sure what causes that, but at a guess it's having to talk to the
> DSA switch over the MDIO bus via several layers of indirect accesses.
> Of course, serial console adds to the boot time significantly anyway,
> especially at the "standard" kernel logging level.

Yes, I don't think it makes any sense to measure boot times with the
serial console on, because it's not comparable to production and
because printing an additional line during boot affects significantly
the times.

To be clear, I was saying that this series should NOT affect total
boot times much.

>> One more thing about the breakage we have seen so far is that it's
>> generally caused by implicit dependencies and hunting those is
>> probably the second biggest timesink of the linux embedded developer
>> after failed probes.
>
> ... which is generally caused by the crappy code which the average
> embedded Linux developer creates, particularly with the crappy error
> messages they like creating.  For the most part, they _might_ as well
> just print "Error!\n" and be done with it, for all the use they are.
> When creating an error print, your average embedded Linux developer
> fails to print the _reason_ why something failed, which makes debugging
> it much harder.
>
> The first thing I do when I touch code that needs this kind of debugging
> is to go through and add printing of the error code.  That normally lets
> me quickly narrow down what's failed.
>
> If embedded Linux developers are struggling with this, they only have
> themselves to blame.
>
> In the case of deferred probing, what _may_ help is if we got rid of the
> core code printing that driver X requested deferred probing, instead
> moving the responsibility to report this onto the driver or subsystem.
> Resource claiming generally has the struct device, and can use dev_warn()
> to report which device is being probed, along with which resource is
> not yet available.

Agreed, with the note from above on why it would be better to only
print such a message only when the -EPROBE_DEFER is likely to be a
problem.

> This debug problem is solvable without needing to resort to complex
> probing solutions.

If you really think anything in this series is complex, you should
look at the other ones that tried to accomplish the same!

Thanks,

Tomeu

> --
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 19 October 2015 at 15:18, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> ... If a device is available and has
>> a compatible driver, but it cannot be probed because a dependency
>> isn't going to be available, that's an error and is going to cause
>> real-world problems unless the device is redundant. Currently we say
>> nothing because with deferred probe the probe callbacks are also part
>> of the mechanism that determines the dependency order.
>
> So what if device X depends on device Y, and we have a driver for
> device Y built-in to the kernel, but the driver for device X is a
> module?
>
> I don't see this being solvable in the way you describe above - it's
> going to identify X as being unable to be satisfied, and report it as
> an error - but it's not an error at all.

It's going to probe Y at late_initcall, then probe X when its driver
is registered. No deferred probes nor messages about it.

But if you meant to write the opposite case (X built-in and Y in a
module), then I have to ask you in what situation that would make
sense.

>> Having a specific switch for enabling deferred probe logging sounds
>> good, but there's going to be hundreds of spurious messages about
>> deferred probes that were just deferrals and only one of them is going
>> to be the actual error in which a device failed to find a dependency.
>
> Why would there be?  Sounds like something's very wrong there.

Sorry about that, I have checked that only now and I "only" get 39
deferred probe messages on exynos5250-snow.

> You should only get deferred probes for devices which are declared to
> be present, but their resources have not yet been satisfied.  It
> doesn't change anything if you have a kernel with lots of device drivers
> or just the device drivers you need - the device drivers you don't need
> do not contribute to the deferred probing in any way.

I don't think that the number of registered drivers affects the number
of probes that get deferred (but I'm not sure why you mention that).

> So, really, after boot and all appropriate modules have been loaded,
> you should end up with no deferred probes.  Are you saying that you
> still have "hundreds" at that point?  If you do, that sounds like
> there's something very wrong.

I was talking about messages if we log each -EPROBE_DEFER, not devices
that remain to be probed. The point being that right now we don't have
a way to know if we are deferring because the dependency will be
around later, or if we have a problem and the dependency isn't going
to be there at all.

If we had a way to enable printing the cause of each -EPROBE_DEFER,
right now that would print 39 messages of this board that are only due
to ordering. The actual issue would be printed in exactly the same way
somewhere in the middle.

>> 3) Regarding total boot time, I don't expect this series to make much
>> of a difference because though we would save a lot of matching and
>> querying for resources, that's little time compared with how long we
>> wait for hardware to react during probing. Async probing is more
>> likely to help with drivers that take a long time to probe.
>
> For me, on my fastest ARM board, though running serial console:
>
> [    2.293468] VFS: Mounted root (ext4 filesystem) on device 179:1.
>
> There's a couple of delays in there, but they're not down to deferred
> probing.  The biggest one is serial console startup (due to the time
> it takes to write out the initial kernel messages):
>
> [    0.289962] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 23, base_baud = 15625000) is a 16550A
> [    0.944124] console [ttyS0] enabled
>
> and DSA switch initialisation:
>
> [    1.530655] libphy: dsa slave smi: probed
> [    2.034426] dsa dsa@0 lan6 (uninitialized): attached PHY at address 0 [Generic PHY]
>
> I'm not sure what causes that, but at a guess it's having to talk to the
> DSA switch over the MDIO bus via several layers of indirect accesses.
> Of course, serial console adds to the boot time significantly anyway,
> especially at the "standard" kernel logging level.

Yes, I don't think it makes any sense to measure boot times with the
serial console on, because it's not comparable to production and
because printing an additional line during boot affects significantly
the times.

To be clear, I was saying that this series should NOT affect total
boot times much.

>> One more thing about the breakage we have seen so far is that it's
>> generally caused by implicit dependencies and hunting those is
>> probably the second biggest timesink of the linux embedded developer
>> after failed probes.
>
> ... which is generally caused by the crappy code which the average
> embedded Linux developer creates, particularly with the crappy error
> messages they like creating.  For the most part, they _might_ as well
> just print "Error!\n" and be done with it, for all the use they are.
> When creating an error print, your average embedded Linux developer
> fails to print the _reason_ why something failed, which makes debugging
> it much harder.
>
> The first thing I do when I touch code that needs this kind of debugging
> is to go through and add printing of the error code.  That normally lets
> me quickly narrow down what's failed.
>
> If embedded Linux developers are struggling with this, they only have
> themselves to blame.
>
> In the case of deferred probing, what _may_ help is if we got rid of the
> core code printing that driver X requested deferred probing, instead
> moving the responsibility to report this onto the driver or subsystem.
> Resource claiming generally has the struct device, and can use dev_warn()
> to report which device is being probed, along with which resource is
> not yet available.

Agreed, with the note from above on why it would be better to only
print such a message only when the -EPROBE_DEFER is likely to be a
problem.

> This debug problem is solvable without needing to resort to complex
> probing solutions.

If you really think anything in this series is complex, you should
look at the other ones that tried to accomplish the same!

Thanks,

Tomeu

> --
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
> On 19 October 2015 at 15:18, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
> >> ... If a device is available and has
> >> a compatible driver, but it cannot be probed because a dependency
> >> isn't going to be available, that's an error and is going to cause
> >> real-world problems unless the device is redundant. Currently we say
> >> nothing because with deferred probe the probe callbacks are also part
> >> of the mechanism that determines the dependency order.
> >
> > So what if device X depends on device Y, and we have a driver for
> > device Y built-in to the kernel, but the driver for device X is a
> > module?
> >
> > I don't see this being solvable in the way you describe above - it's
> > going to identify X as being unable to be satisfied, and report it as
> > an error - but it's not an error at all.
> 
> It's going to probe Y at late_initcall, then probe X when its driver
> is registered. No deferred probes nor messages about it.
> 
> But if you meant to write the opposite case (X built-in and Y in a
> module), then I have to ask you in what situation that would make
> sense.

I did mean the opposite way around.  It may not make sense if you're
targetting a single platform, but it may make sense in a single zImage
kernel.

Consider something like a single zImage kernel that is built with
everything built-in to be able to boot and mount rootfs without
initramfs support on both platform A and platform B.  Both platforms
share some hardware (eg, an I2C GPIO expander) which is built as a
module.  It is a resource provider.  Platform B contains a driver
which is required to boot on platform A, but not platform B (so the
kernel has to have that driver built-in.)  On platform B, there is
a dependency to the I2C GPIO expander device.

> >> Having a specific switch for enabling deferred probe logging sounds
> >> good, but there's going to be hundreds of spurious messages about
> >> deferred probes that were just deferrals and only one of them is going
> >> to be the actual error in which a device failed to find a dependency.
> >
> > Why would there be?  Sounds like something's very wrong there.
> 
> Sorry about that, I have checked that only now and I "only" get 39
> deferred probe messages on exynos5250-snow.

I typically see one or two, maybe five maximum on the platforms I have
here, but normally zero.

> > So, really, after boot and all appropriate modules have been loaded,
> > you should end up with no deferred probes.  Are you saying that you
> > still have "hundreds" at that point?  If you do, that sounds like
> > there's something very wrong.
> 
> I was talking about messages if we log each -EPROBE_DEFER, not devices
> that remain to be probed. The point being that right now we don't have
> a way to know if we are deferring because the dependency will be
> around later, or if we have a problem and the dependency isn't going
> to be there at all.

What's the difference between a dependency which isn't around because
the driver is not built into the kernel but is available as a module,
and a dependency that isn't around because the module hasn't been
loaded yet?

How do you distinguish between those two scenarios?  In the former
scenario, the device will eventually come up when udev loads the
module.  In the latter case, it's a persistent failing case.

> Agreed, with the note from above on why it would be better to only
> print such a message only when the -EPROBE_DEFER is likely to be a
> problem.

... and my argument is that there's _no way_ to know for certain which
deferred probes will be a problem, and which won't.  The only way to
definitely know that is if you disable kernel modules, and require
all drivers to be built into the kernel.

What you can do is print those devices which have failed to probe at
late_initcall() time - possibly augmenting that with reports from
subsystems showing what resources are not available, but that's only
a guide, because of the "it might or might not be in a kernel module"
problem.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
> On 19 October 2015 at 15:18, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
> >> ... If a device is available and has
> >> a compatible driver, but it cannot be probed because a dependency
> >> isn't going to be available, that's an error and is going to cause
> >> real-world problems unless the device is redundant. Currently we say
> >> nothing because with deferred probe the probe callbacks are also part
> >> of the mechanism that determines the dependency order.
> >
> > So what if device X depends on device Y, and we have a driver for
> > device Y built-in to the kernel, but the driver for device X is a
> > module?
> >
> > I don't see this being solvable in the way you describe above - it's
> > going to identify X as being unable to be satisfied, and report it as
> > an error - but it's not an error at all.
> 
> It's going to probe Y at late_initcall, then probe X when its driver
> is registered. No deferred probes nor messages about it.
> 
> But if you meant to write the opposite case (X built-in and Y in a
> module), then I have to ask you in what situation that would make
> sense.

I did mean the opposite way around.  It may not make sense if you're
targetting a single platform, but it may make sense in a single zImage
kernel.

Consider something like a single zImage kernel that is built with
everything built-in to be able to boot and mount rootfs without
initramfs support on both platform A and platform B.  Both platforms
share some hardware (eg, an I2C GPIO expander) which is built as a
module.  It is a resource provider.  Platform B contains a driver
which is required to boot on platform A, but not platform B (so the
kernel has to have that driver built-in.)  On platform B, there is
a dependency to the I2C GPIO expander device.

> >> Having a specific switch for enabling deferred probe logging sounds
> >> good, but there's going to be hundreds of spurious messages about
> >> deferred probes that were just deferrals and only one of them is going
> >> to be the actual error in which a device failed to find a dependency.
> >
> > Why would there be?  Sounds like something's very wrong there.
> 
> Sorry about that, I have checked that only now and I "only" get 39
> deferred probe messages on exynos5250-snow.

I typically see one or two, maybe five maximum on the platforms I have
here, but normally zero.

> > So, really, after boot and all appropriate modules have been loaded,
> > you should end up with no deferred probes.  Are you saying that you
> > still have "hundreds" at that point?  If you do, that sounds like
> > there's something very wrong.
> 
> I was talking about messages if we log each -EPROBE_DEFER, not devices
> that remain to be probed. The point being that right now we don't have
> a way to know if we are deferring because the dependency will be
> around later, or if we have a problem and the dependency isn't going
> to be there at all.

What's the difference between a dependency which isn't around because
the driver is not built into the kernel but is available as a module,
and a dependency that isn't around because the module hasn't been
loaded yet?

How do you distinguish between those two scenarios?  In the former
scenario, the device will eventually come up when udev loads the
module.  In the latter case, it's a persistent failing case.

> Agreed, with the note from above on why it would be better to only
> print such a message only when the -EPROBE_DEFER is likely to be a
> problem.

... and my argument is that there's _no way_ to know for certain which
deferred probes will be a problem, and which won't.  The only way to
definitely know that is if you disable kernel modules, and require
all drivers to be built into the kernel.

What you can do is print those devices which have failed to probe at
late_initcall() time - possibly augmenting that with reports from
subsystems showing what resources are not available, but that's only
a guide, because of the "it might or might not be in a kernel module"
problem.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
> On 19 October 2015 at 15:18, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
> >> ... If a device is available and has
> >> a compatible driver, but it cannot be probed because a dependency
> >> isn't going to be available, that's an error and is going to cause
> >> real-world problems unless the device is redundant. Currently we say
> >> nothing because with deferred probe the probe callbacks are also part
> >> of the mechanism that determines the dependency order.
> >
> > So what if device X depends on device Y, and we have a driver for
> > device Y built-in to the kernel, but the driver for device X is a
> > module?
> >
> > I don't see this being solvable in the way you describe above - it's
> > going to identify X as being unable to be satisfied, and report it as
> > an error - but it's not an error at all.
> 
> It's going to probe Y at late_initcall, then probe X when its driver
> is registered. No deferred probes nor messages about it.
> 
> But if you meant to write the opposite case (X built-in and Y in a
> module), then I have to ask you in what situation that would make
> sense.

I did mean the opposite way around.  It may not make sense if you're
targetting a single platform, but it may make sense in a single zImage
kernel.

Consider something like a single zImage kernel that is built with
everything built-in to be able to boot and mount rootfs without
initramfs support on both platform A and platform B.  Both platforms
share some hardware (eg, an I2C GPIO expander) which is built as a
module.  It is a resource provider.  Platform B contains a driver
which is required to boot on platform A, but not platform B (so the
kernel has to have that driver built-in.)  On platform B, there is
a dependency to the I2C GPIO expander device.

> >> Having a specific switch for enabling deferred probe logging sounds
> >> good, but there's going to be hundreds of spurious messages about
> >> deferred probes that were just deferrals and only one of them is going
> >> to be the actual error in which a device failed to find a dependency.
> >
> > Why would there be?  Sounds like something's very wrong there.
> 
> Sorry about that, I have checked that only now and I "only" get 39
> deferred probe messages on exynos5250-snow.

I typically see one or two, maybe five maximum on the platforms I have
here, but normally zero.

> > So, really, after boot and all appropriate modules have been loaded,
> > you should end up with no deferred probes.  Are you saying that you
> > still have "hundreds" at that point?  If you do, that sounds like
> > there's something very wrong.
> 
> I was talking about messages if we log each -EPROBE_DEFER, not devices
> that remain to be probed. The point being that right now we don't have
> a way to know if we are deferring because the dependency will be
> around later, or if we have a problem and the dependency isn't going
> to be there at all.

What's the difference between a dependency which isn't around because
the driver is not built into the kernel but is available as a module,
and a dependency that isn't around because the module hasn't been
loaded yet?

How do you distinguish between those two scenarios?  In the former
scenario, the device will eventually come up when udev loads the
module.  In the latter case, it's a persistent failing case.

> Agreed, with the note from above on why it would be better to only
> print such a message only when the -EPROBE_DEFER is likely to be a
> problem.

... and my argument is that there's _no way_ to know for certain which
deferred probes will be a problem, and which won't.  The only way to
definitely know that is if you disable kernel modules, and require
all drivers to be built into the kernel.

What you can do is print those devices which have failed to probe at
late_initcall() time - possibly augmenting that with reports from
subsystems showing what resources are not available, but that's only
a guide, because of the "it might or might not be in a kernel module"
problem.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1921 bytes --]

On Mon, Oct 19, 2015 at 01:47:50PM +0100, David Woodhouse wrote:
> On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:

> > See version 2 of the series[1] which did that. It became obvious that
> > was pointless because the call paths ended up looking like this:

> > Generic subsystem code -> DT look-up code -> fwnode_probe_device ->
> > of_probe_device

> You link to a thread which says that "AT LEAST CURRENTLY, the calling
> locations [the 'DT look-up code' you mention above] are DT specific
> functions anyway.

> But the point I'm making is that we are working towards *fixing* that,
> and *not* using DT-specific code in places where we should be using the
> generic APIs.

What is the plan for fixing things here?  It's not obvious (at least to
me) that we don't want to have the subsystems having knowledge of how
they are bound to a specific firmware which is what you seem to imply
here.  That seems like it's going to fall down since the different
firmware interfaces do have quite different ideas about how things fit
together at a system level and different compatibility needs which do
suggest that just trying to do a direct mapping from DT into ACPI may
well not make people happy but it sounds like that's the intention.

When it gets to drivers the situation is much more clear since it's
normally just simple properties, it's generally a bit more worrying if
drivers are needing to directly interact with cross-device linkage.
This is all subsystem level code though.

> None of that really negates that fact that we are *working* on cleaning
> these code paths up to be firmware-agnostic, and the fact that we
> haven't got to this one *yet* isn't necessarily a good reason to make
> it *worse* by adding new firmware-specificity to it.

It seems like we're going to have to refactor these bits of code when
they get generalised anyway so I'm not sure that the additional cost
here is that big.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1921 bytes --]

On Mon, Oct 19, 2015 at 01:47:50PM +0100, David Woodhouse wrote:
> On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:

> > See version 2 of the series[1] which did that. It became obvious that
> > was pointless because the call paths ended up looking like this:

> > Generic subsystem code -> DT look-up code -> fwnode_probe_device ->
> > of_probe_device

> You link to a thread which says that "AT LEAST CURRENTLY, the calling
> locations [the 'DT look-up code' you mention above] are DT specific
> functions anyway.

> But the point I'm making is that we are working towards *fixing* that,
> and *not* using DT-specific code in places where we should be using the
> generic APIs.

What is the plan for fixing things here?  It's not obvious (at least to
me) that we don't want to have the subsystems having knowledge of how
they are bound to a specific firmware which is what you seem to imply
here.  That seems like it's going to fall down since the different
firmware interfaces do have quite different ideas about how things fit
together at a system level and different compatibility needs which do
suggest that just trying to do a direct mapping from DT into ACPI may
well not make people happy but it sounds like that's the intention.

When it gets to drivers the situation is much more clear since it's
normally just simple properties, it's generally a bit more worrying if
drivers are needing to directly interact with cross-device linkage.
This is all subsystem level code though.

> None of that really negates that fact that we are *working* on cleaning
> these code paths up to be firmware-agnostic, and the fact that we
> haven't got to this one *yet* isn't necessarily a good reason to make
> it *worse* by adding new firmware-specificity to it.

It seems like we're going to have to refactor these bits of code when
they get generalised anyway so I'm not sure that the additional cost
here is that big.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1921 bytes --]

On Mon, Oct 19, 2015 at 01:47:50PM +0100, David Woodhouse wrote:
> On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:

> > See version 2 of the series[1] which did that. It became obvious that
> > was pointless because the call paths ended up looking like this:

> > Generic subsystem code -> DT look-up code -> fwnode_probe_device ->
> > of_probe_device

> You link to a thread which says that "AT LEAST CURRENTLY, the calling
> locations [the 'DT look-up code' you mention above] are DT specific
> functions anyway.

> But the point I'm making is that we are working towards *fixing* that,
> and *not* using DT-specific code in places where we should be using the
> generic APIs.

What is the plan for fixing things here?  It's not obvious (at least to
me) that we don't want to have the subsystems having knowledge of how
they are bound to a specific firmware which is what you seem to imply
here.  That seems like it's going to fall down since the different
firmware interfaces do have quite different ideas about how things fit
together at a system level and different compatibility needs which do
suggest that just trying to do a direct mapping from DT into ACPI may
well not make people happy but it sounds like that's the intention.

When it gets to drivers the situation is much more clear since it's
normally just simple properties, it's generally a bit more worrying if
drivers are needing to directly interact with cross-device linkage.
This is all subsystem level code though.

> None of that really negates that fact that we are *working* on cleaning
> these code paths up to be firmware-agnostic, and the fact that we
> haven't got to this one *yet* isn't necessarily a good reason to make
> it *worse* by adding new firmware-specificity to it.

It seems like we're going to have to refactor these bits of code when
they get generalised anyway so I'm not sure that the additional cost
here is that big.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 19 October 2015 at 16:30, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
>> On 19 October 2015 at 15:18, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> >> ... If a device is available and has
>> >> a compatible driver, but it cannot be probed because a dependency
>> >> isn't going to be available, that's an error and is going to cause
>> >> real-world problems unless the device is redundant. Currently we say
>> >> nothing because with deferred probe the probe callbacks are also part
>> >> of the mechanism that determines the dependency order.
>> >
>> > So what if device X depends on device Y, and we have a driver for
>> > device Y built-in to the kernel, but the driver for device X is a
>> > module?
>> >
>> > I don't see this being solvable in the way you describe above - it's
>> > going to identify X as being unable to be satisfied, and report it as
>> > an error - but it's not an error at all.
>>
>> It's going to probe Y at late_initcall, then probe X when its driver
>> is registered. No deferred probes nor messages about it.
>>
>> But if you meant to write the opposite case (X built-in and Y in a
>> module), then I have to ask you in what situation that would make
>> sense.
>
> I did mean the opposite way around.  It may not make sense if you're
> targetting a single platform, but it may make sense in a single zImage
> kernel.
>
> Consider something like a single zImage kernel that is built with
> everything built-in to be able to boot and mount rootfs without
> initramfs support on both platform A and platform B.  Both platforms
> share some hardware (eg, an I2C GPIO expander) which is built as a
> module.  It is a resource provider.  Platform B contains a driver
> which is required to boot on platform A, but not platform B (so the
> kernel has to have that driver built-in.)  On platform B, there is
> a dependency to the I2C GPIO expander device.

I see, in this situation the person trying to find out why some device
hadn't probed would enable debug logging of failed probes and would
see one spurious message if there was a deferred probe because of the
module.

>> >> Having a specific switch for enabling deferred probe logging sounds
>> >> good, but there's going to be hundreds of spurious messages about
>> >> deferred probes that were just deferrals and only one of them is going
>> >> to be the actual error in which a device failed to find a dependency.
>> >
>> > Why would there be?  Sounds like something's very wrong there.
>>
>> Sorry about that, I have checked that only now and I "only" get 39
>> deferred probe messages on exynos5250-snow.
>
> I typically see one or two, maybe five maximum on the platforms I have
> here, but normally zero.

Hmm, I have given a look at our lava farm and have seen 2 dozens as
common (with multi_v7).

>> > So, really, after boot and all appropriate modules have been loaded,
>> > you should end up with no deferred probes.  Are you saying that you
>> > still have "hundreds" at that point?  If you do, that sounds like
>> > there's something very wrong.
>>
>> I was talking about messages if we log each -EPROBE_DEFER, not devices
>> that remain to be probed. The point being that right now we don't have
>> a way to know if we are deferring because the dependency will be
>> around later, or if we have a problem and the dependency isn't going
>> to be there at all.
>
> What's the difference between a dependency which isn't around because
> the driver is not built into the kernel but is available as a module,
> and a dependency that isn't around because the module hasn't been
> loaded yet?
>
> How do you distinguish between those two scenarios?  In the former
> scenario, the device will eventually come up when udev loads the
> module.  In the latter case, it's a persistent failing case.

Agreed, but it's something that doesn't happen often and that's why
such messages would be at the debug level instead of being warns or
errors.

>> Agreed, with the note from above on why it would be better to only
>> print such a message only when the -EPROBE_DEFER is likely to be a
>> problem.
>
> ... and my argument is that there's _no way_ to know for certain which
> deferred probes will be a problem, and which won't.  The only way to
> definitely know that is if you disable kernel modules, and require
> all drivers to be built into the kernel.
>
> What you can do is print those devices which have failed to probe at
> late_initcall() time - possibly augmenting that with reports from
> subsystems showing what resources are not available, but that's only
> a guide, because of the "it might or might not be in a kernel module"
> problem.

Well, adding those reports would give you a changelog similar to the
one in this series...

Thanks,

Tomeu

> --
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 19 October 2015 at 16:30, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
>> On 19 October 2015 at 15:18, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> >> ... If a device is available and has
>> >> a compatible driver, but it cannot be probed because a dependency
>> >> isn't going to be available, that's an error and is going to cause
>> >> real-world problems unless the device is redundant. Currently we say
>> >> nothing because with deferred probe the probe callbacks are also part
>> >> of the mechanism that determines the dependency order.
>> >
>> > So what if device X depends on device Y, and we have a driver for
>> > device Y built-in to the kernel, but the driver for device X is a
>> > module?
>> >
>> > I don't see this being solvable in the way you describe above - it's
>> > going to identify X as being unable to be satisfied, and report it as
>> > an error - but it's not an error at all.
>>
>> It's going to probe Y at late_initcall, then probe X when its driver
>> is registered. No deferred probes nor messages about it.
>>
>> But if you meant to write the opposite case (X built-in and Y in a
>> module), then I have to ask you in what situation that would make
>> sense.
>
> I did mean the opposite way around.  It may not make sense if you're
> targetting a single platform, but it may make sense in a single zImage
> kernel.
>
> Consider something like a single zImage kernel that is built with
> everything built-in to be able to boot and mount rootfs without
> initramfs support on both platform A and platform B.  Both platforms
> share some hardware (eg, an I2C GPIO expander) which is built as a
> module.  It is a resource provider.  Platform B contains a driver
> which is required to boot on platform A, but not platform B (so the
> kernel has to have that driver built-in.)  On platform B, there is
> a dependency to the I2C GPIO expander device.

I see, in this situation the person trying to find out why some device
hadn't probed would enable debug logging of failed probes and would
see one spurious message if there was a deferred probe because of the
module.

>> >> Having a specific switch for enabling deferred probe logging sounds
>> >> good, but there's going to be hundreds of spurious messages about
>> >> deferred probes that were just deferrals and only one of them is going
>> >> to be the actual error in which a device failed to find a dependency.
>> >
>> > Why would there be?  Sounds like something's very wrong there.
>>
>> Sorry about that, I have checked that only now and I "only" get 39
>> deferred probe messages on exynos5250-snow.
>
> I typically see one or two, maybe five maximum on the platforms I have
> here, but normally zero.

Hmm, I have given a look at our lava farm and have seen 2 dozens as
common (with multi_v7).

>> > So, really, after boot and all appropriate modules have been loaded,
>> > you should end up with no deferred probes.  Are you saying that you
>> > still have "hundreds" at that point?  If you do, that sounds like
>> > there's something very wrong.
>>
>> I was talking about messages if we log each -EPROBE_DEFER, not devices
>> that remain to be probed. The point being that right now we don't have
>> a way to know if we are deferring because the dependency will be
>> around later, or if we have a problem and the dependency isn't going
>> to be there at all.
>
> What's the difference between a dependency which isn't around because
> the driver is not built into the kernel but is available as a module,
> and a dependency that isn't around because the module hasn't been
> loaded yet?
>
> How do you distinguish between those two scenarios?  In the former
> scenario, the device will eventually come up when udev loads the
> module.  In the latter case, it's a persistent failing case.

Agreed, but it's something that doesn't happen often and that's why
such messages would be at the debug level instead of being warns or
errors.

>> Agreed, with the note from above on why it would be better to only
>> print such a message only when the -EPROBE_DEFER is likely to be a
>> problem.
>
> ... and my argument is that there's _no way_ to know for certain which
> deferred probes will be a problem, and which won't.  The only way to
> definitely know that is if you disable kernel modules, and require
> all drivers to be built into the kernel.
>
> What you can do is print those devices which have failed to probe at
> late_initcall() time - possibly augmenting that with reports from
> subsystems showing what resources are not available, but that's only
> a guide, because of the "it might or might not be in a kernel module"
> problem.

Well, adding those reports would give you a changelog similar to the
one in this series...

Thanks,

Tomeu

> --
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 19 October 2015 at 16:30, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
>> On 19 October 2015 at 15:18, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> >> ... If a device is available and has
>> >> a compatible driver, but it cannot be probed because a dependency
>> >> isn't going to be available, that's an error and is going to cause
>> >> real-world problems unless the device is redundant. Currently we say
>> >> nothing because with deferred probe the probe callbacks are also part
>> >> of the mechanism that determines the dependency order.
>> >
>> > So what if device X depends on device Y, and we have a driver for
>> > device Y built-in to the kernel, but the driver for device X is a
>> > module?
>> >
>> > I don't see this being solvable in the way you describe above - it's
>> > going to identify X as being unable to be satisfied, and report it as
>> > an error - but it's not an error at all.
>>
>> It's going to probe Y at late_initcall, then probe X when its driver
>> is registered. No deferred probes nor messages about it.
>>
>> But if you meant to write the opposite case (X built-in and Y in a
>> module), then I have to ask you in what situation that would make
>> sense.
>
> I did mean the opposite way around.  It may not make sense if you're
> targetting a single platform, but it may make sense in a single zImage
> kernel.
>
> Consider something like a single zImage kernel that is built with
> everything built-in to be able to boot and mount rootfs without
> initramfs support on both platform A and platform B.  Both platforms
> share some hardware (eg, an I2C GPIO expander) which is built as a
> module.  It is a resource provider.  Platform B contains a driver
> which is required to boot on platform A, but not platform B (so the
> kernel has to have that driver built-in.)  On platform B, there is
> a dependency to the I2C GPIO expander device.

I see, in this situation the person trying to find out why some device
hadn't probed would enable debug logging of failed probes and would
see one spurious message if there was a deferred probe because of the
module.

>> >> Having a specific switch for enabling deferred probe logging sounds
>> >> good, but there's going to be hundreds of spurious messages about
>> >> deferred probes that were just deferrals and only one of them is going
>> >> to be the actual error in which a device failed to find a dependency.
>> >
>> > Why would there be?  Sounds like something's very wrong there.
>>
>> Sorry about that, I have checked that only now and I "only" get 39
>> deferred probe messages on exynos5250-snow.
>
> I typically see one or two, maybe five maximum on the platforms I have
> here, but normally zero.

Hmm, I have given a look at our lava farm and have seen 2 dozens as
common (with multi_v7).

>> > So, really, after boot and all appropriate modules have been loaded,
>> > you should end up with no deferred probes.  Are you saying that you
>> > still have "hundreds" at that point?  If you do, that sounds like
>> > there's something very wrong.
>>
>> I was talking about messages if we log each -EPROBE_DEFER, not devices
>> that remain to be probed. The point being that right now we don't have
>> a way to know if we are deferring because the dependency will be
>> around later, or if we have a problem and the dependency isn't going
>> to be there at all.
>
> What's the difference between a dependency which isn't around because
> the driver is not built into the kernel but is available as a module,
> and a dependency that isn't around because the module hasn't been
> loaded yet?
>
> How do you distinguish between those two scenarios?  In the former
> scenario, the device will eventually come up when udev loads the
> module.  In the latter case, it's a persistent failing case.

Agreed, but it's something that doesn't happen often and that's why
such messages would be at the debug level instead of being warns or
errors.

>> Agreed, with the note from above on why it would be better to only
>> print such a message only when the -EPROBE_DEFER is likely to be a
>> problem.
>
> ... and my argument is that there's _no way_ to know for certain which
> deferred probes will be a problem, and which won't.  The only way to
> definitely know that is if you disable kernel modules, and require
> all drivers to be built into the kernel.
>
> What you can do is print those devices which have failed to probe at
> late_initcall() time - possibly augmenting that with reports from
> subsystems showing what resources are not available, but that's only
> a guide, because of the "it might or might not be in a kernel module"
> problem.

Well, adding those reports would give you a changelog similar to the
one in this series...

Thanks,

Tomeu

> --
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> > But the point I'm making is that we are working towards *fixing* that,
> > and *not* using DT-specific code in places where we should be using the
> > generic APIs.
> 
> What is the plan for fixing things here?  It's not obvious (at least to
> me) that we don't want to have the subsystems having knowledge of how
> they are bound to a specific firmware which is what you seem to imply
> here. 

I don't know that there *is* a coherent plan here to address it all.

Certainly, we *will* need subsystems to have firmware-specific
knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
describe GPIO, and properties which reference GPIO pins are intended to
work through that — while in DT, properties which reference GPIO pins
will have different contents. They'll be compatible at the driver
level, in the sense that there's a call to get a given GPIO given the
property name, but the subsystems *will* be doing different things
behind the scenes.

My plan, such as it is, is to go through the leaf-node drivers which
almost definitely *should* be firmware-agnostic, and convert those. And
then take stock of what we have left, and work out what, if anything,
still needs to be done.

> It seems like we're going to have to refactor these bits of code when
> they get generalised anyway so I'm not sure that the additional cost
> here is that big.

That's an acceptable answer — "we're adding legacy code here but we
know it's going to be refactored anyway". If that's true, all it takes
is a note in the commit comment to that effect. That's different from
having not thought about it :)

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [GIT PULL] On-demand device probing

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> > But the point I'm making is that we are working towards *fixing* that,
> > and *not* using DT-specific code in places where we should be using the
> > generic APIs.
> 
> What is the plan for fixing things here?  It's not obvious (at least to
> me) that we don't want to have the subsystems having knowledge of how
> they are bound to a specific firmware which is what you seem to imply
> here. 

I don't know that there *is* a coherent plan here to address it all.

Certainly, we *will* need subsystems to have firmware-specific
knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
describe GPIO, and properties which reference GPIO pins are intended to
work through that — while in DT, properties which reference GPIO pins
will have different contents. They'll be compatible at the driver
level, in the sense that there's a call to get a given GPIO given the
property name, but the subsystems *will* be doing different things
behind the scenes.

My plan, such as it is, is to go through the leaf-node drivers which
almost definitely *should* be firmware-agnostic, and convert those. And
then take stock of what we have left, and work out what, if anything,
still needs to be done.

> It seems like we're going to have to refactor these bits of code when
> they get generalised anyway so I'm not sure that the additional cost
> here is that big.

That's an acceptable answer — "we're adding legacy code here but we
know it's going to be refactored anyway". If that's true, all it takes
is a note in the commit comment to that effect. That's different from
having not thought about it :)

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [GIT PULL] On-demand device probing

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> > But the point I'm making is that we are working towards *fixing* that,
> > and *not* using DT-specific code in places where we should be using the
> > generic APIs.
> 
> What is the plan for fixing things here?  It's not obvious (at least to
> me) that we don't want to have the subsystems having knowledge of how
> they are bound to a specific firmware which is what you seem to imply
> here. 

I don't know that there *is* a coherent plan here to address it all.

Certainly, we *will* need subsystems to have firmware-specific
knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
describe GPIO, and properties which reference GPIO pins are intended to
work through that — while in DT, properties which reference GPIO pins
will have different contents. They'll be compatible at the driver
level, in the sense that there's a call to get a given GPIO given the
property name, but the subsystems *will* be doing different things
behind the scenes.

My plan, such as it is, is to go through the leaf-node drivers which
almost definitely *should* be firmware-agnostic, and convert those. And
then take stock of what we have left, and work out what, if anything,
still needs to be done.

> It seems like we're going to have to refactor these bits of code when
> they get generalised anyway so I'm not sure that the additional cost
> here is that big.

That's an acceptable answer — "we're adding legacy code here but we
know it's going to be refactored anyway". If that's true, all it takes
is a note in the commit comment to that effect. That's different from
having not thought about it :)

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 05:00:54PM +0200, Tomeu Vizoso wrote:
> On 19 October 2015 at 16:30, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > I typically see one or two, maybe five maximum on the platforms I have
> > here, but normally zero.
> 
> Hmm, I have given a look at our lava farm and have seen 2 dozens as
> common (with multi_v7).

No, because the lava farms tend not to be public.

> > What you can do is print those devices which have failed to probe at
> > late_initcall() time - possibly augmenting that with reports from
> > subsystems showing what resources are not available, but that's only
> > a guide, because of the "it might or might not be in a kernel module"
> > problem.
> 
> Well, adding those reports would give you a changelog similar to the
> one in this series...

I'm not sure about that, because what I was thinking of is adding
a flag which would be set at late_initcall() time prior to running
a final round of deferred device probing.

This flag would then be used in a deferred_warn() printk function
which would normally be silent, but when this flag is set, it would
print the reason for the deferral - and this would replace (or be
added) to the subsystems and drivers which return -EPROBE_DEFER.

That has the effect of hiding all the deferrals up until just before
launching into userspace, which should then acomplish two things -
firstly, getting rid of the rather useless deferred messages up to
that point, and secondly printing the reason why the remaining
deferrals are happening.

That should be a small number of new lines plus a one-line change
in subsystems and drivers.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 05:00:54PM +0200, Tomeu Vizoso wrote:
> On 19 October 2015 at 16:30, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > I typically see one or two, maybe five maximum on the platforms I have
> > here, but normally zero.
> 
> Hmm, I have given a look at our lava farm and have seen 2 dozens as
> common (with multi_v7).

No, because the lava farms tend not to be public.

> > What you can do is print those devices which have failed to probe at
> > late_initcall() time - possibly augmenting that with reports from
> > subsystems showing what resources are not available, but that's only
> > a guide, because of the "it might or might not be in a kernel module"
> > problem.
> 
> Well, adding those reports would give you a changelog similar to the
> one in this series...

I'm not sure about that, because what I was thinking of is adding
a flag which would be set at late_initcall() time prior to running
a final round of deferred device probing.

This flag would then be used in a deferred_warn() printk function
which would normally be silent, but when this flag is set, it would
print the reason for the deferral - and this would replace (or be
added) to the subsystems and drivers which return -EPROBE_DEFER.

That has the effect of hiding all the deferrals up until just before
launching into userspace, which should then acomplish two things -
firstly, getting rid of the rather useless deferred messages up to
that point, and secondly printing the reason why the remaining
deferrals are happening.

That should be a small number of new lines plus a one-line change
in subsystems and drivers.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 05:00:54PM +0200, Tomeu Vizoso wrote:
> On 19 October 2015 at 16:30, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > I typically see one or two, maybe five maximum on the platforms I have
> > here, but normally zero.
> 
> Hmm, I have given a look at our lava farm and have seen 2 dozens as
> common (with multi_v7).

No, because the lava farms tend not to be public.

> > What you can do is print those devices which have failed to probe at
> > late_initcall() time - possibly augmenting that with reports from
> > subsystems showing what resources are not available, but that's only
> > a guide, because of the "it might or might not be in a kernel module"
> > problem.
> 
> Well, adding those reports would give you a changelog similar to the
> one in this series...

I'm not sure about that, because what I was thinking of is adding
a flag which would be set at late_initcall() time prior to running
a final round of deferred device probing.

This flag would then be used in a deferred_warn() printk function
which would normally be silent, but when this flag is set, it would
print the reason for the deferral - and this would replace (or be
added) to the subsystems and drivers which return -EPROBE_DEFER.

That has the effect of hiding all the deferrals up until just before
launching into userspace, which should then acomplish two things -
firstly, getting rid of the rather useless deferred messages up to
that point, and secondly printing the reason why the remaining
deferrals are happening.

That should be a small number of new lines plus a one-line change
in subsystems and drivers.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> I don't know that there *is* a coherent plan here to address it all.
> 
> Certainly, we *will* need subsystems to have firmware-specific
> knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> describe GPIO, and properties which reference GPIO pins are intended to
> work through that — while in DT, properties which reference GPIO pins
> will have different contents. They'll be compatible at the driver
> level, in the sense that there's a call to get a given GPIO given the
> property name, but the subsystems *will* be doing different things
> behind the scenes.

It's a bit ironic that you've chosen GPIO as an example there.  The
"new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
gpio descriptor.  There's no of_* method.

I'd like to use the gpiod_* stuff, but I feel that my options are
rather limited: either use fwnode_get_named_gpiod() with
&dev->of_node->fwnode, which seems like a hack by going underneath
the covers of how fwnode is (partially) implemented with DT, or by
using of_get_named_gpio() and the converting the gpio number to a
descriptor via gpio_to_desc().  Both feel very hacky.

If ACPI already handles GPIOs internally, then I'm left wondering
why GPIO descriptor stuff went down the fwnode route at all - it
seems rather pointless in this case, and it seems to make the use
of the gpiod* interfaces where we _do_ need to use it (DT) harder
and more hacky.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> I don't know that there *is* a coherent plan here to address it all.
> 
> Certainly, we *will* need subsystems to have firmware-specific
> knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> describe GPIO, and properties which reference GPIO pins are intended to
> work through that — while in DT, properties which reference GPIO pins
> will have different contents. They'll be compatible at the driver
> level, in the sense that there's a call to get a given GPIO given the
> property name, but the subsystems *will* be doing different things
> behind the scenes.

It's a bit ironic that you've chosen GPIO as an example there.  The
"new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
gpio descriptor.  There's no of_* method.

I'd like to use the gpiod_* stuff, but I feel that my options are
rather limited: either use fwnode_get_named_gpiod() with
&dev->of_node->fwnode, which seems like a hack by going underneath
the covers of how fwnode is (partially) implemented with DT, or by
using of_get_named_gpio() and the converting the gpio number to a
descriptor via gpio_to_desc().  Both feel very hacky.

If ACPI already handles GPIOs internally, then I'm left wondering
why GPIO descriptor stuff went down the fwnode route at all - it
seems rather pointless in this case, and it seems to make the use
of the gpiod* interfaces where we _do_ need to use it (DT) harder
and more hacky.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> I don't know that there *is* a coherent plan here to address it all.
> 
> Certainly, we *will* need subsystems to have firmware-specific
> knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> describe GPIO, and properties which reference GPIO pins are intended to
> work through that — while in DT, properties which reference GPIO pins
> will have different contents. They'll be compatible at the driver
> level, in the sense that there's a call to get a given GPIO given the
> property name, but the subsystems *will* be doing different things
> behind the scenes.

It's a bit ironic that you've chosen GPIO as an example there.  The
"new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
gpio descriptor.  There's no of_* method.

I'd like to use the gpiod_* stuff, but I feel that my options are
rather limited: either use fwnode_get_named_gpiod() with
&dev->of_node->fwnode, which seems like a hack by going underneath
the covers of how fwnode is (partially) implemented with DT, or by
using of_get_named_gpio() and the converting the gpio number to a
descriptor via gpio_to_desc().  Both feel very hacky.

If ACPI already handles GPIOs internally, then I'm left wondering
why GPIO descriptor stuff went down the fwnode route at all - it
seems rather pointless in this case, and it seems to make the use
of the gpiod* interfaces where we _do_ need to use it (DT) harder
and more hacky.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> > But the point I'm making is that we are working towards *fixing* that,
>> > and *not* using DT-specific code in places where we should be using the
>> > generic APIs.
>>
>> What is the plan for fixing things here?  It's not obvious (at least to
>> me) that we don't want to have the subsystems having knowledge of how
>> they are bound to a specific firmware which is what you seem to imply
>> here.
>
> I don't know that there *is* a coherent plan here to address it all.
>
> Certainly, we *will* need subsystems to have firmware-specific
> knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> describe GPIO, and properties which reference GPIO pins are intended to
> work through that — while in DT, properties which reference GPIO pins
> will have different contents. They'll be compatible at the driver
> level, in the sense that there's a call to get a given GPIO given the
> property name, but the subsystems *will* be doing different things
> behind the scenes.
>
> My plan, such as it is, is to go through the leaf-node drivers which
> almost definitely *should* be firmware-agnostic, and convert those. And
> then take stock of what we have left, and work out what, if anything,
> still needs to be done.

Many cases are already agnostic in the drivers in terms of the *_get()
functions. Some are DT specific, but probably because those subsystems
are new and DT only. In any case, I don't think these 1 line changes
do anything to make doing conversions here harder.

>> It seems like we're going to have to refactor these bits of code when
>> they get generalised anyway so I'm not sure that the additional cost
>> here is that big.
>
> That's an acceptable answer — "we're adding legacy code here but we
> know it's going to be refactored anyway". If that's true, all it takes
> is a note in the commit comment to that effect. That's different from
> having not thought about it :)

Considering at one point we did create a fwnode based API, we did
think about it. Plus there was little input from ACPI folks as to
whether the change was even useful for ACPI case. In any case, we're
talking about adding 1 line.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> > But the point I'm making is that we are working towards *fixing* that,
>> > and *not* using DT-specific code in places where we should be using the
>> > generic APIs.
>>
>> What is the plan for fixing things here?  It's not obvious (at least to
>> me) that we don't want to have the subsystems having knowledge of how
>> they are bound to a specific firmware which is what you seem to imply
>> here.
>
> I don't know that there *is* a coherent plan here to address it all.
>
> Certainly, we *will* need subsystems to have firmware-specific
> knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> describe GPIO, and properties which reference GPIO pins are intended to
> work through that — while in DT, properties which reference GPIO pins
> will have different contents. They'll be compatible at the driver
> level, in the sense that there's a call to get a given GPIO given the
> property name, but the subsystems *will* be doing different things
> behind the scenes.
>
> My plan, such as it is, is to go through the leaf-node drivers which
> almost definitely *should* be firmware-agnostic, and convert those. And
> then take stock of what we have left, and work out what, if anything,
> still needs to be done.

Many cases are already agnostic in the drivers in terms of the *_get()
functions. Some are DT specific, but probably because those subsystems
are new and DT only. In any case, I don't think these 1 line changes
do anything to make doing conversions here harder.

>> It seems like we're going to have to refactor these bits of code when
>> they get generalised anyway so I'm not sure that the additional cost
>> here is that big.
>
> That's an acceptable answer — "we're adding legacy code here but we
> know it's going to be refactored anyway". If that's true, all it takes
> is a note in the commit comment to that effect. That's different from
> having not thought about it :)

Considering at one point we did create a fwnode based API, we did
think about it. Plus there was little input from ACPI folks as to
whether the change was even useful for ACPI case. In any case, we're
talking about adding 1 line.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wro=
te:
> On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> > But the point I'm making is that we are working towards *fixing* that,
>> > and *not* using DT-specific code in places where we should be using th=
e
>> > generic APIs.
>>
>> What is the plan for fixing things here?  It's not obvious (at least to
>> me) that we don't want to have the subsystems having knowledge of how
>> they are bound to a specific firmware which is what you seem to imply
>> here.
>
> I don't know that there *is* a coherent plan here to address it all.
>
> Certainly, we *will* need subsystems to have firmware-specific
> knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> describe GPIO, and properties which reference GPIO pins are intended to
> work through that =E2=80=94 while in DT, properties which reference GPIO =
pins
> will have different contents. They'll be compatible at the driver
> level, in the sense that there's a call to get a given GPIO given the
> property name, but the subsystems *will* be doing different things
> behind the scenes.
>
> My plan, such as it is, is to go through the leaf-node drivers which
> almost definitely *should* be firmware-agnostic, and convert those. And
> then take stock of what we have left, and work out what, if anything,
> still needs to be done.

Many cases are already agnostic in the drivers in terms of the *_get()
functions. Some are DT specific, but probably because those subsystems
are new and DT only. In any case, I don't think these 1 line changes
do anything to make doing conversions here harder.

>> It seems like we're going to have to refactor these bits of code when
>> they get generalised anyway so I'm not sure that the additional cost
>> here is that big.
>
> That's an acceptable answer =E2=80=94 "we're adding legacy code here but =
we
> know it's going to be refactored anyway". If that's true, all it takes
> is a note in the commit comment to that effect. That's different from
> having not thought about it :)

Considering at one point we did create a fwnode based API, we did
think about it. Plus there was little input from ACPI folks as to
whether the change was even useful for ACPI case. In any case, we're
talking about adding 1 line.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> > But the point I'm making is that we are working towards *fixing* that,
>> > and *not* using DT-specific code in places where we should be using the
>> > generic APIs.
>>
>> What is the plan for fixing things here?  It's not obvious (at least to
>> me) that we don't want to have the subsystems having knowledge of how
>> they are bound to a specific firmware which is what you seem to imply
>> here.
>
> I don't know that there *is* a coherent plan here to address it all.
>
> Certainly, we *will* need subsystems to have firmware-specific
> knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> describe GPIO, and properties which reference GPIO pins are intended to
> work through that — while in DT, properties which reference GPIO pins
> will have different contents. They'll be compatible at the driver
> level, in the sense that there's a call to get a given GPIO given the
> property name, but the subsystems *will* be doing different things
> behind the scenes.
>
> My plan, such as it is, is to go through the leaf-node drivers which
> almost definitely *should* be firmware-agnostic, and convert those. And
> then take stock of what we have left, and work out what, if anything,
> still needs to be done.

Many cases are already agnostic in the drivers in terms of the *_get()
functions. Some are DT specific, but probably because those subsystems
are new and DT only. In any case, I don't think these 1 line changes
do anything to make doing conversions here harder.

>> It seems like we're going to have to refactor these bits of code when
>> they get generalised anyway so I'm not sure that the additional cost
>> here is that big.
>
> That's an acceptable answer — "we're adding legacy code here but we
> know it's going to be refactored anyway". If that's true, all it takes
> is a note in the commit comment to that effect. That's different from
> having not thought about it :)

Considering at one point we did create a fwnode based API, we did
think about it. Plus there was little input from ACPI folks as to
whether the change was even useful for ACPI case. In any case, we're
talking about adding 1 line.

Rob

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> > > But the point I'm making is that we are working towards *fixing* that,
> > > and *not* using DT-specific code in places where we should be using the
> > > generic APIs.

> > What is the plan for fixing things here?  It's not obvious (at least to
> > me) that we don't want to have the subsystems having knowledge of how
> > they are bound to a specific firmware which is what you seem to imply
> > here. 

> I don't know that there *is* a coherent plan here to address it all.

> Certainly, we *will* need subsystems to have firmware-specific
> knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> describe GPIO, and properties which reference GPIO pins are intended to
> work through that — while in DT, properties which reference GPIO pins
> will have different contents. They'll be compatible at the driver
> level, in the sense that there's a call to get a given GPIO given the
> property name, but the subsystems *will* be doing different things
> behind the scenes.

I'd expect that to be the norm rather than the exception.

> > It seems like we're going to have to refactor these bits of code when
> > they get generalised anyway so I'm not sure that the additional cost
> > here is that big.

> That's an acceptable answer — "we're adding legacy code here but we
> know it's going to be refactored anyway". If that's true, all it takes
> is a note in the commit comment to that effect. That's different from
> having not thought about it :)

Given the above I'm not even sure it's legacy code, it's just as likely
we're going to get some parallel ACPI code added to the subsystems for
parsing their bindings.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> > > But the point I'm making is that we are working towards *fixing* that,
> > > and *not* using DT-specific code in places where we should be using the
> > > generic APIs.

> > What is the plan for fixing things here?  It's not obvious (at least to
> > me) that we don't want to have the subsystems having knowledge of how
> > they are bound to a specific firmware which is what you seem to imply
> > here. 

> I don't know that there *is* a coherent plan here to address it all.

> Certainly, we *will* need subsystems to have firmware-specific
> knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> describe GPIO, and properties which reference GPIO pins are intended to
> work through that — while in DT, properties which reference GPIO pins
> will have different contents. They'll be compatible at the driver
> level, in the sense that there's a call to get a given GPIO given the
> property name, but the subsystems *will* be doing different things
> behind the scenes.

I'd expect that to be the norm rather than the exception.

> > It seems like we're going to have to refactor these bits of code when
> > they get generalised anyway so I'm not sure that the additional cost
> > here is that big.

> That's an acceptable answer — "we're adding legacy code here but we
> know it's going to be refactored anyway". If that's true, all it takes
> is a note in the commit comment to that effect. That's different from
> having not thought about it :)

Given the above I'm not even sure it's legacy code, it's just as likely
we're going to get some parallel ACPI code added to the subsystems for
parsing their bindings.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> > > But the point I'm making is that we are working towards *fixing* that,
> > > and *not* using DT-specific code in places where we should be using the
> > > generic APIs.

> > What is the plan for fixing things here?  It's not obvious (at least to
> > me) that we don't want to have the subsystems having knowledge of how
> > they are bound to a specific firmware which is what you seem to imply
> > here. 

> I don't know that there *is* a coherent plan here to address it all.

> Certainly, we *will* need subsystems to have firmware-specific
> knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> describe GPIO, and properties which reference GPIO pins are intended to
> work through that — while in DT, properties which reference GPIO pins
> will have different contents. They'll be compatible at the driver
> level, in the sense that there's a call to get a given GPIO given the
> property name, but the subsystems *will* be doing different things
> behind the scenes.

I'd expect that to be the norm rather than the exception.

> > It seems like we're going to have to refactor these bits of code when
> > they get generalised anyway so I'm not sure that the additional cost
> > here is that big.

> That's an acceptable answer — "we're adding legacy code here but we
> know it's going to be refactored anyway". If that's true, all it takes
> is a note in the commit comment to that effect. That's different from
> having not thought about it :)

Given the above I'm not even sure it's legacy code, it's just as likely
we're going to get some parallel ACPI code added to the subsystems for
parsing their bindings.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Geert Uytterhoeven]

Hi Russell,

On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>> > What you can do is print those devices which have failed to probe at
>> > late_initcall() time - possibly augmenting that with reports from
>> > subsystems showing what resources are not available, but that's only
>> > a guide, because of the "it might or might not be in a kernel module"
>> > problem.
>>
>> Well, adding those reports would give you a changelog similar to the
>> one in this series...
>
> I'm not sure about that, because what I was thinking of is adding
> a flag which would be set at late_initcall() time prior to running
> a final round of deferred device probing.

Which round is the final round?
That's the one which didn't manage to bind any new devices to drivers,
which is something you only know _after_ the round has been run.

So I think we need one extra round to handle this.

> This flag would then be used in a deferred_warn() printk function
> which would normally be silent, but when this flag is set, it would
> print the reason for the deferral - and this would replace (or be
> added) to the subsystems and drivers which return -EPROBE_DEFER.
>
> That has the effect of hiding all the deferrals up until just before
> launching into userspace, which should then acomplish two things -
> firstly, getting rid of the rather useless deferred messages up to
> that point, and secondly printing the reason why the remaining
> deferrals are happening.
>
> That should be a small number of new lines plus a one-line change
> in subsystems and drivers.

Apart from the extra round we probably can't get rid of, that sounds OK to me.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] On-demand device probing

[Geert Uytterhoeven]

Hi Russell,

On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>> > What you can do is print those devices which have failed to probe at
>> > late_initcall() time - possibly augmenting that with reports from
>> > subsystems showing what resources are not available, but that's only
>> > a guide, because of the "it might or might not be in a kernel module"
>> > problem.
>>
>> Well, adding those reports would give you a changelog similar to the
>> one in this series...
>
> I'm not sure about that, because what I was thinking of is adding
> a flag which would be set at late_initcall() time prior to running
> a final round of deferred device probing.

Which round is the final round?
That's the one which didn't manage to bind any new devices to drivers,
which is something you only know _after_ the round has been run.

So I think we need one extra round to handle this.

> This flag would then be used in a deferred_warn() printk function
> which would normally be silent, but when this flag is set, it would
> print the reason for the deferral - and this would replace (or be
> added) to the subsystems and drivers which return -EPROBE_DEFER.
>
> That has the effect of hiding all the deferrals up until just before
> launching into userspace, which should then acomplish two things -
> firstly, getting rid of the rather useless deferred messages up to
> that point, and secondly printing the reason why the remaining
> deferrals are happening.
>
> That should be a small number of new lines plus a one-line change
> in subsystems and drivers.

Apart from the extra round we probably can't get rid of, that sounds OK to me.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] On-demand device probing

[Geert Uytterhoeven]

Hi Russell,

On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>> > What you can do is print those devices which have failed to probe at
>> > late_initcall() time - possibly augmenting that with reports from
>> > subsystems showing what resources are not available, but that's only
>> > a guide, because of the "it might or might not be in a kernel module"
>> > problem.
>>
>> Well, adding those reports would give you a changelog similar to the
>> one in this series...
>
> I'm not sure about that, because what I was thinking of is adding
> a flag which would be set at late_initcall() time prior to running
> a final round of deferred device probing.

Which round is the final round?
That's the one which didn't manage to bind any new devices to drivers,
which is something you only know _after_ the round has been run.

So I think we need one extra round to handle this.

> This flag would then be used in a deferred_warn() printk function
> which would normally be silent, but when this flag is set, it would
> print the reason for the deferral - and this would replace (or be
> added) to the subsystems and drivers which return -EPROBE_DEFER.
>
> That has the effect of hiding all the deferrals up until just before
> launching into userspace, which should then acomplish two things -
> firstly, getting rid of the rather useless deferred messages up to
> that point, and secondly printing the reason why the remaining
> deferrals are happening.
>
> That should be a small number of new lines plus a one-line change
> in subsystems and drivers.

Apart from the extra round we probably can't get rid of, that sounds OK to me.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - possibly augmenting that with reports from
> >> > subsystems showing what resources are not available, but that's only
> >> > a guide, because of the "it might or might not be in a kernel module"
> >> > problem.
> >>
> >> Well, adding those reports would give you a changelog similar to the
> >> one in this series...
> >
> > I'm not sure about that, because what I was thinking of is adding
> > a flag which would be set at late_initcall() time prior to running
> > a final round of deferred device probing.
> 
> Which round is the final round?

I said "a" not "the".  Maybe I should've said "one last round of deferred
probing before entering userspace".

> That's the one which didn't manage to bind any new devices to drivers,
> which is something you only know _after_ the round has been run.
> 
> So I think we need one extra round to handle this.

Yes - because the idea is that we do everything we do today without
printing anything about deferred probes.  We then set a flag which
indicates we should report defers, and then we trigger another round
of probes.

If everything probed successfully, the deferred probe list will be
empty and nothing will be seen.  Otherwise, we should end up with a
report of all the devices that weren't able to be bound to their
drivers due to -EPROBE_DEFER.

> 
> > This flag would then be used in a deferred_warn() printk function
> > which would normally be silent, but when this flag is set, it would
> > print the reason for the deferral - and this would replace (or be
> > added) to the subsystems and drivers which return -EPROBE_DEFER.
> >
> > That has the effect of hiding all the deferrals up until just before
> > launching into userspace, which should then acomplish two things -
> > firstly, getting rid of the rather useless deferred messages up to
> > that point, and secondly printing the reason why the remaining
> > deferrals are happening.
> >
> > That should be a small number of new lines plus a one-line change
> > in subsystems and drivers.
> 
> Apart from the extra round we probably can't get rid of, that sounds
> OK to me.

Yes, it means a little longer to boot, but if there's nothing pending
this _should_ only be microseconds - it should be nothing more than
setting the flag, possibly taking and releasing a lock, and checking
that the deferred probe list is empty.

Of course, if the deferred probe list isn't empty, then there'll be
more expense - but I'm willing to bet that for those developers with
serial console enabled, the kernel boot will be faster overall due
to the reduced number of characters printed during the boot.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - possibly augmenting that with reports from
> >> > subsystems showing what resources are not available, but that's only
> >> > a guide, because of the "it might or might not be in a kernel module"
> >> > problem.
> >>
> >> Well, adding those reports would give you a changelog similar to the
> >> one in this series...
> >
> > I'm not sure about that, because what I was thinking of is adding
> > a flag which would be set at late_initcall() time prior to running
> > a final round of deferred device probing.
> 
> Which round is the final round?

I said "a" not "the".  Maybe I should've said "one last round of deferred
probing before entering userspace".

> That's the one which didn't manage to bind any new devices to drivers,
> which is something you only know _after_ the round has been run.
> 
> So I think we need one extra round to handle this.

Yes - because the idea is that we do everything we do today without
printing anything about deferred probes.  We then set a flag which
indicates we should report defers, and then we trigger another round
of probes.

If everything probed successfully, the deferred probe list will be
empty and nothing will be seen.  Otherwise, we should end up with a
report of all the devices that weren't able to be bound to their
drivers due to -EPROBE_DEFER.

> 
> > This flag would then be used in a deferred_warn() printk function
> > which would normally be silent, but when this flag is set, it would
> > print the reason for the deferral - and this would replace (or be
> > added) to the subsystems and drivers which return -EPROBE_DEFER.
> >
> > That has the effect of hiding all the deferrals up until just before
> > launching into userspace, which should then acomplish two things -
> > firstly, getting rid of the rather useless deferred messages up to
> > that point, and secondly printing the reason why the remaining
> > deferrals are happening.
> >
> > That should be a small number of new lines plus a one-line change
> > in subsystems and drivers.
> 
> Apart from the extra round we probably can't get rid of, that sounds
> OK to me.

Yes, it means a little longer to boot, but if there's nothing pending
this _should_ only be microseconds - it should be nothing more than
setting the flag, possibly taking and releasing a lock, and checking
that the deferred probe list is empty.

Of course, if the deferred probe list isn't empty, then there'll be
more expense - but I'm willing to bet that for those developers with
serial console enabled, the kernel boot will be faster overall due
to the reduced number of characters printed during the boot.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - possibly augmenting that with reports from
> >> > subsystems showing what resources are not available, but that's only
> >> > a guide, because of the "it might or might not be in a kernel module"
> >> > problem.
> >>
> >> Well, adding those reports would give you a changelog similar to the
> >> one in this series...
> >
> > I'm not sure about that, because what I was thinking of is adding
> > a flag which would be set at late_initcall() time prior to running
> > a final round of deferred device probing.
> 
> Which round is the final round?

I said "a" not "the".  Maybe I should've said "one last round of deferred
probing before entering userspace".

> That's the one which didn't manage to bind any new devices to drivers,
> which is something you only know _after_ the round has been run.
> 
> So I think we need one extra round to handle this.

Yes - because the idea is that we do everything we do today without
printing anything about deferred probes.  We then set a flag which
indicates we should report defers, and then we trigger another round
of probes.

If everything probed successfully, the deferred probe list will be
empty and nothing will be seen.  Otherwise, we should end up with a
report of all the devices that weren't able to be bound to their
drivers due to -EPROBE_DEFER.

> 
> > This flag would then be used in a deferred_warn() printk function
> > which would normally be silent, but when this flag is set, it would
> > print the reason for the deferral - and this would replace (or be
> > added) to the subsystems and drivers which return -EPROBE_DEFER.
> >
> > That has the effect of hiding all the deferrals up until just before
> > launching into userspace, which should then acomplish two things -
> > firstly, getting rid of the rather useless deferred messages up to
> > that point, and secondly printing the reason why the remaining
> > deferrals are happening.
> >
> > That should be a small number of new lines plus a one-line change
> > in subsystems and drivers.
> 
> Apart from the extra round we probably can't get rid of, that sounds
> OK to me.

Yes, it means a little longer to boot, but if there's nothing pending
this _should_ only be microseconds - it should be nothing more than
setting the flag, possibly taking and releasing a lock, and checking
that the deferred probe list is empty.

Of course, if the deferred probe list isn't empty, then there'll be
more expense - but I'm willing to bet that for those developers with
serial console enabled, the kernel boot will be faster overall due
to the reduced number of characters printed during the boot.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Olof Johansson]

On Sat, Oct 17, 2015 at 8:19 AM, Rob Herring <robh+dt@kernel.org> wrote:
> On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson <olof@lixom.net> wrote:
>> Hi,
>>
>> I've bisected boot failures in next-20151016 down to patches in this branch:
>>
>> On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
>> <tomeu.vizoso@collabora.com> wrote:
>>> Tomeu Vizoso (20):
>>>       driver core: handle -EPROBE_DEFER from bus_type.match()
>>
>> The machine it happened on was OMAP5UEVM:
>>
>> http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html
>
> So this one is because the MMC node numbering changed. I don't know
> how to fix that other than with aliases, but that doesn't solve
> backwards compatibility.

Yep, aliases will take care of it in this case. This is where -next
fills a great purpose, we can make sure we get those aliases added in
before the patches go in.

>> But I've also seen it on tegra2, that one bisected down to:
>>
>>>      regulator: core: Probe regulators on demand
>>
>> http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html
>
> This one you need a rootwait I think. The MMC scanning is not
> guaranteed to be done before the rootfs mounting AFAIK. There may be
> other problems, but we can't see them since it panics.

Embarrassing, I almost always do this and I'm surprised this machine
has been this stable without it.


-Olof

Re: [GIT PULL] On-demand device probing

[Olof Johansson]

On Sat, Oct 17, 2015 at 8:19 AM, Rob Herring <robh+dt@kernel.org> wrote:
> On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson <olof@lixom.net> wrote:
>> Hi,
>>
>> I've bisected boot failures in next-20151016 down to patches in this branch:
>>
>> On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
>> <tomeu.vizoso@collabora.com> wrote:
>>> Tomeu Vizoso (20):
>>>       driver core: handle -EPROBE_DEFER from bus_type.match()
>>
>> The machine it happened on was OMAP5UEVM:
>>
>> http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html
>
> So this one is because the MMC node numbering changed. I don't know
> how to fix that other than with aliases, but that doesn't solve
> backwards compatibility.

Yep, aliases will take care of it in this case. This is where -next
fills a great purpose, we can make sure we get those aliases added in
before the patches go in.

>> But I've also seen it on tegra2, that one bisected down to:
>>
>>>      regulator: core: Probe regulators on demand
>>
>> http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html
>
> This one you need a rootwait I think. The MMC scanning is not
> guaranteed to be done before the rootfs mounting AFAIK. There may be
> other problems, but we can't see them since it panics.

Embarrassing, I almost always do this and I'm surprised this machine
has been this stable without it.


-Olof

Re: [GIT PULL] On-demand device probing

[Olof Johansson]

On Sat, Oct 17, 2015 at 8:19 AM, Rob Herring <robh+dt@kernel.org> wrote:
> On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson <olof@lixom.net> wrote:
>> Hi,
>>
>> I've bisected boot failures in next-20151016 down to patches in this branch:
>>
>> On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso
>> <tomeu.vizoso@collabora.com> wrote:
>>> Tomeu Vizoso (20):
>>>       driver core: handle -EPROBE_DEFER from bus_type.match()
>>
>> The machine it happened on was OMAP5UEVM:
>>
>> http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html
>
> So this one is because the MMC node numbering changed. I don't know
> how to fix that other than with aliases, but that doesn't solve
> backwards compatibility.

Yep, aliases will take care of it in this case. This is where -next
fills a great purpose, we can make sure we get those aliases added in
before the patches go in.

>> But I've also seen it on tegra2, that one bisected down to:
>>
>>>      regulator: core: Probe regulators on demand
>>
>> http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html
>
> This one you need a rootwait I think. The MMC scanning is not
> guaranteed to be done before the rootfs mounting AFAIK. There may be
> other problems, but we can't see them since it panics.

Embarrassing, I almost always do this and I'm surprised this machine
has been this stable without it.


-Olof

Re: [GIT PULL] On-demand device probing

[Uwe Kleine-König]

Hello,

On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
> It's a bit ironic that you've chosen GPIO as an example there.  The
> "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
> gpio descriptor.  There's no of_* method.

Without following all that fwnode discussion:
gpiod_get et al. should work for you here, doesn't it? It just takes a
struct device * and I'm happy with it.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [GIT PULL] On-demand device probing

[Uwe Kleine-König]

Hello,

On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
> It's a bit ironic that you've chosen GPIO as an example there.  The
> "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
> gpio descriptor.  There's no of_* method.

Without following all that fwnode discussion:
gpiod_get et al. should work for you here, doesn't it? It just takes a
struct device * and I'm happy with it.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [GIT PULL] On-demand device probing

[Uwe Kleine-König]

Hello,

On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
> It's a bit ironic that you've chosen GPIO as an example there.  The
> "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
> gpio descriptor.  There's no of_* method.

Without following all that fwnode discussion:
gpiod_get et al. should work for you here, doesn't it? It just takes a
struct device * and I'm happy with it.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
> > It's a bit ironic that you've chosen GPIO as an example there.  The
> > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
> > gpio descriptor.  There's no of_* method.
> 
> Without following all that fwnode discussion:
> gpiod_get et al. should work for you here, doesn't it? It just takes a
> struct device * and I'm happy with it.

What if you don't have a struct device?  I had that problem recently
when modifying the mvebu PCIe code.  The 'struct device' node doesn't
contain the GPIOs, it's the PCIe controller.  Individual ports on the
controller are described in DT as sub-nodes, and the sub-nodes can
have a GPIO for card reset purposes.  These sub-nodes don't have a
struct device.

Right now, I'm having to do this to work around this issue:

        reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, &flags);
        if (reset_gpio == -EPROBE_DEFER) {
                ret = reset_gpio;
                goto err;
        }

        if (gpio_is_valid(reset_gpio)) {
                unsigned long gpio_flags;

                port->reset_name = devm_kasprintf(dev, GFP_KERNEL, "%s-reset",
                                                  port->name);
                if (!port->reset_name) {
                        ret = -ENOMEM;
                        goto err;
                }

                if (flags & OF_GPIO_ACTIVE_LOW) {
                        dev_info(dev, "%s: reset gpio is active low\n",
                                 of_node_full_name(child));
                        gpio_flags = GPIOF_ACTIVE_LOW |
                                     GPIOF_OUT_INIT_LOW;
                } else {
                        gpio_flags = GPIOF_OUT_INIT_HIGH;
                }

                ret = devm_gpio_request_one(dev, reset_gpio, gpio_flags,
                                            port->reset_name);
                if (ret) {
                        if (ret == -EPROBE_DEFER)
                                goto err;
                        goto skip;
                }

                port->reset_gpio = gpio_to_desc(reset_gpio);
        }

Not nice, is it?  Not nice to have that in lots of drivers either.

However, switching to use any of_* or fwnode_* thing also carries with
it another problem: you can't control the name appearing in the
allocation, so you end up with a bunch of GPIOs requested with a "reset"
name - meaning you lose any identification of which port the GPIO was
bound to.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
> > It's a bit ironic that you've chosen GPIO as an example there.  The
> > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
> > gpio descriptor.  There's no of_* method.
> 
> Without following all that fwnode discussion:
> gpiod_get et al. should work for you here, doesn't it? It just takes a
> struct device * and I'm happy with it.

What if you don't have a struct device?  I had that problem recently
when modifying the mvebu PCIe code.  The 'struct device' node doesn't
contain the GPIOs, it's the PCIe controller.  Individual ports on the
controller are described in DT as sub-nodes, and the sub-nodes can
have a GPIO for card reset purposes.  These sub-nodes don't have a
struct device.

Right now, I'm having to do this to work around this issue:

        reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, &flags);
        if (reset_gpio == -EPROBE_DEFER) {
                ret = reset_gpio;
                goto err;
        }

        if (gpio_is_valid(reset_gpio)) {
                unsigned long gpio_flags;

                port->reset_name = devm_kasprintf(dev, GFP_KERNEL, "%s-reset",
                                                  port->name);
                if (!port->reset_name) {
                        ret = -ENOMEM;
                        goto err;
                }

                if (flags & OF_GPIO_ACTIVE_LOW) {
                        dev_info(dev, "%s: reset gpio is active low\n",
                                 of_node_full_name(child));
                        gpio_flags = GPIOF_ACTIVE_LOW |
                                     GPIOF_OUT_INIT_LOW;
                } else {
                        gpio_flags = GPIOF_OUT_INIT_HIGH;
                }

                ret = devm_gpio_request_one(dev, reset_gpio, gpio_flags,
                                            port->reset_name);
                if (ret) {
                        if (ret == -EPROBE_DEFER)
                                goto err;
                        goto skip;
                }

                port->reset_gpio = gpio_to_desc(reset_gpio);
        }

Not nice, is it?  Not nice to have that in lots of drivers either.

However, switching to use any of_* or fwnode_* thing also carries with
it another problem: you can't control the name appearing in the
allocation, so you end up with a bunch of GPIOs requested with a "reset"
name - meaning you lose any identification of which port the GPIO was
bound to.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
> > It's a bit ironic that you've chosen GPIO as an example there.  The
> > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
> > gpio descriptor.  There's no of_* method.
> 
> Without following all that fwnode discussion:
> gpiod_get et al. should work for you here, doesn't it? It just takes a
> struct device * and I'm happy with it.

What if you don't have a struct device?  I had that problem recently
when modifying the mvebu PCIe code.  The 'struct device' node doesn't
contain the GPIOs, it's the PCIe controller.  Individual ports on the
controller are described in DT as sub-nodes, and the sub-nodes can
have a GPIO for card reset purposes.  These sub-nodes don't have a
struct device.

Right now, I'm having to do this to work around this issue:

        reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, &flags);
        if (reset_gpio = -EPROBE_DEFER) {
                ret = reset_gpio;
                goto err;
        }

        if (gpio_is_valid(reset_gpio)) {
                unsigned long gpio_flags;

                port->reset_name = devm_kasprintf(dev, GFP_KERNEL, "%s-reset",
                                                  port->name);
                if (!port->reset_name) {
                        ret = -ENOMEM;
                        goto err;
                }

                if (flags & OF_GPIO_ACTIVE_LOW) {
                        dev_info(dev, "%s: reset gpio is active low\n",
                                 of_node_full_name(child));
                        gpio_flags = GPIOF_ACTIVE_LOW |
                                     GPIOF_OUT_INIT_LOW;
                } else {
                        gpio_flags = GPIOF_OUT_INIT_HIGH;
                }

                ret = devm_gpio_request_one(dev, reset_gpio, gpio_flags,
                                            port->reset_name);
                if (ret) {
                        if (ret = -EPROBE_DEFER)
                                goto err;
                        goto skip;
                }

                port->reset_gpio = gpio_to_desc(reset_gpio);
        }

Not nice, is it?  Not nice to have that in lots of drivers either.

However, switching to use any of_* or fwnode_* thing also carries with
it another problem: you can't control the name appearing in the
allocation, so you end up with a bunch of GPIOs requested with a "reset"
name - meaning you lose any identification of which port the GPIO was
bound to.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> > But the point I'm making is that we are working towards *fixing* that,
> >> > and *not* using DT-specific code in places where we should be using the
> >> > generic APIs.
> >>
> >> What is the plan for fixing things here?  It's not obvious (at least to
> >> me) that we don't want to have the subsystems having knowledge of how
> >> they are bound to a specific firmware which is what you seem to imply
> >> here.
> >
> > I don't know that there *is* a coherent plan here to address it all.
> >
> > Certainly, we *will* need subsystems to have firmware-specific
> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> > describe GPIO, and properties which reference GPIO pins are intended to
> > work through that — while in DT, properties which reference GPIO pins
> > will have different contents. They'll be compatible at the driver
> > level, in the sense that there's a call to get a given GPIO given the
> > property name, but the subsystems *will* be doing different things
> > behind the scenes.
> >
> > My plan, such as it is, is to go through the leaf-node drivers which
> > almost definitely *should* be firmware-agnostic, and convert those. And
> > then take stock of what we have left, and work out what, if anything,
> > still needs to be done.
> 
> Many cases are already agnostic in the drivers in terms of the *_get()
> functions. Some are DT specific, but probably because those subsystems
> are new and DT only. In any case, I don't think these 1 line changes
> do anything to make doing conversions here harder.
> 
> >> It seems like we're going to have to refactor these bits of code when
> >> they get generalised anyway so I'm not sure that the additional cost
> >> here is that big.
> >
> > That's an acceptable answer — "we're adding legacy code here but we
> > know it's going to be refactored anyway". If that's true, all it takes
> > is a note in the commit comment to that effect. That's different from
> > having not thought about it :)
> 
> Considering at one point we did create a fwnode based API, we did
> think about it. Plus there was little input from ACPI folks as to
> whether the change was even useful for ACPI case.

Well, sorry, but who was asking whom, specifically?

The underlying problem is present in ACPI too and we don't really have a good
solution for it.  We might benefit from a common one if it existed.

> In any case, we're talking about adding 1 line.

But also about making the driver core slighly OF-centric.

Sure, we need OF-specific code and ACPI-specific code wherever different
handling is required, but doing that at the driver core level seems to be
a bit of a stretch to me.

Please note that we don't really have ACPI-specific calls in the driver core,
although we might have added them long ago even before the OF stuff appeared
in the kernel for the first time.  We didn't do that, (among other things)
because we didn't want that particular firmware interface to appear special
in any way and I'm not really sure why it is now OK to make OF look special
instead.

If it is trivial to avoid that (and you seem to be arguing that it is), why
do we have to do it?

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> > But the point I'm making is that we are working towards *fixing* that,
> >> > and *not* using DT-specific code in places where we should be using the
> >> > generic APIs.
> >>
> >> What is the plan for fixing things here?  It's not obvious (at least to
> >> me) that we don't want to have the subsystems having knowledge of how
> >> they are bound to a specific firmware which is what you seem to imply
> >> here.
> >
> > I don't know that there *is* a coherent plan here to address it all.
> >
> > Certainly, we *will* need subsystems to have firmware-specific
> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> > describe GPIO, and properties which reference GPIO pins are intended to
> > work through that — while in DT, properties which reference GPIO pins
> > will have different contents. They'll be compatible at the driver
> > level, in the sense that there's a call to get a given GPIO given the
> > property name, but the subsystems *will* be doing different things
> > behind the scenes.
> >
> > My plan, such as it is, is to go through the leaf-node drivers which
> > almost definitely *should* be firmware-agnostic, and convert those. And
> > then take stock of what we have left, and work out what, if anything,
> > still needs to be done.
> 
> Many cases are already agnostic in the drivers in terms of the *_get()
> functions. Some are DT specific, but probably because those subsystems
> are new and DT only. In any case, I don't think these 1 line changes
> do anything to make doing conversions here harder.
> 
> >> It seems like we're going to have to refactor these bits of code when
> >> they get generalised anyway so I'm not sure that the additional cost
> >> here is that big.
> >
> > That's an acceptable answer — "we're adding legacy code here but we
> > know it's going to be refactored anyway". If that's true, all it takes
> > is a note in the commit comment to that effect. That's different from
> > having not thought about it :)
> 
> Considering at one point we did create a fwnode based API, we did
> think about it. Plus there was little input from ACPI folks as to
> whether the change was even useful for ACPI case.

Well, sorry, but who was asking whom, specifically?

The underlying problem is present in ACPI too and we don't really have a good
solution for it.  We might benefit from a common one if it existed.

> In any case, we're talking about adding 1 line.

But also about making the driver core slighly OF-centric.

Sure, we need OF-specific code and ACPI-specific code wherever different
handling is required, but doing that at the driver core level seems to be
a bit of a stretch to me.

Please note that we don't really have ACPI-specific calls in the driver core,
although we might have added them long ago even before the OF stuff appeared
in the kernel for the first time.  We didn't do that, (among other things)
because we didn't want that particular firmware interface to appear special
in any way and I'm not really sure why it is now OK to make OF look special
instead.

If it is trivial to avoid that (and you seem to be arguing that it is), why
do we have to do it?

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.or=
g> wrote:
> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> > But the point I'm making is that we are working towards *fixing*=
 that,
> >> > and *not* using DT-specific code in places where we should be us=
ing the
> >> > generic APIs.
> >>
> >> What is the plan for fixing things here?  It's not obvious (at lea=
st to
> >> me) that we don't want to have the subsystems having knowledge of =
how
> >> they are bound to a specific firmware which is what you seem to im=
ply
> >> here.
> >
> > I don't know that there *is* a coherent plan here to address it all=
.
> >
> > Certainly, we *will* need subsystems to have firmware-specific
> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way =
to
> > describe GPIO, and properties which reference GPIO pins are intende=
d to
> > work through that =E2=80=94 while in DT, properties which reference=
 GPIO pins
> > will have different contents. They'll be compatible at the driver
> > level, in the sense that there's a call to get a given GPIO given t=
he
> > property name, but the subsystems *will* be doing different things
> > behind the scenes.
> >
> > My plan, such as it is, is to go through the leaf-node drivers whic=
h
> > almost definitely *should* be firmware-agnostic, and convert those.=
 And
> > then take stock of what we have left, and work out what, if anythin=
g,
> > still needs to be done.
>=20
> Many cases are already agnostic in the drivers in terms of the *_get(=
)
> functions. Some are DT specific, but probably because those subsystem=
s
> are new and DT only. In any case, I don't think these 1 line changes
> do anything to make doing conversions here harder.
>=20
> >> It seems like we're going to have to refactor these bits of code w=
hen
> >> they get generalised anyway so I'm not sure that the additional co=
st
> >> here is that big.
> >
> > That's an acceptable answer =E2=80=94 "we're adding legacy code her=
e but we
> > know it's going to be refactored anyway". If that's true, all it ta=
kes
> > is a note in the commit comment to that effect. That's different fr=
om
> > having not thought about it :)
>=20
> Considering at one point we did create a fwnode based API, we did
> think about it. Plus there was little input from ACPI folks as to
> whether the change was even useful for ACPI case.

Well, sorry, but who was asking whom, specifically?

The underlying problem is present in ACPI too and we don't really have =
a good
solution for it.  We might benefit from a common one if it existed.

> In any case, we're talking about adding 1 line.

But also about making the driver core slighly OF-centric.

Sure, we need OF-specific code and ACPI-specific code wherever differen=
t
handling is required, but doing that at the driver core level seems to =
be
a bit of a stretch to me.

Please note that we don't really have ACPI-specific calls in the driver=
 core,
although we might have added them long ago even before the OF stuff app=
eared
in the kernel for the first time.  We didn't do that, (among other thin=
gs)
because we didn't want that particular firmware interface to appear spe=
cial
in any way and I'm not really sure why it is now OK to make OF look spe=
cial
instead.

If it is trivial to avoid that (and you seem to be arguing that it is),=
 why
do we have to do it?

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> > But the point I'm making is that we are working towards *fixing* that,
> >> > and *not* using DT-specific code in places where we should be using the
> >> > generic APIs.
> >>
> >> What is the plan for fixing things here?  It's not obvious (at least to
> >> me) that we don't want to have the subsystems having knowledge of how
> >> they are bound to a specific firmware which is what you seem to imply
> >> here.
> >
> > I don't know that there *is* a coherent plan here to address it all.
> >
> > Certainly, we *will* need subsystems to have firmware-specific
> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> > describe GPIO, and properties which reference GPIO pins are intended to
> > work through that — while in DT, properties which reference GPIO pins
> > will have different contents. They'll be compatible at the driver
> > level, in the sense that there's a call to get a given GPIO given the
> > property name, but the subsystems *will* be doing different things
> > behind the scenes.
> >
> > My plan, such as it is, is to go through the leaf-node drivers which
> > almost definitely *should* be firmware-agnostic, and convert those. And
> > then take stock of what we have left, and work out what, if anything,
> > still needs to be done.
> 
> Many cases are already agnostic in the drivers in terms of the *_get()
> functions. Some are DT specific, but probably because those subsystems
> are new and DT only. In any case, I don't think these 1 line changes
> do anything to make doing conversions here harder.
> 
> >> It seems like we're going to have to refactor these bits of code when
> >> they get generalised anyway so I'm not sure that the additional cost
> >> here is that big.
> >
> > That's an acceptable answer — "we're adding legacy code here but we
> > know it's going to be refactored anyway". If that's true, all it takes
> > is a note in the commit comment to that effect. That's different from
> > having not thought about it :)
> 
> Considering at one point we did create a fwnode based API, we did
> think about it. Plus there was little input from ACPI folks as to
> whether the change was even useful for ACPI case.

Well, sorry, but who was asking whom, specifically?

The underlying problem is present in ACPI too and we don't really have a good
solution for it.  We might benefit from a common one if it existed.

> In any case, we're talking about adding 1 line.

But also about making the driver core slighly OF-centric.

Sure, we need OF-specific code and ACPI-specific code wherever different
handling is required, but doing that at the driver core level seems to be
a bit of a stretch to me.

Please note that we don't really have ACPI-specific calls in the driver core,
although we might have added them long ago even before the OF stuff appeared
in the kernel for the first time.  We didn't do that, (among other things)
because we didn't want that particular firmware interface to appear special
in any way and I'm not really sure why it is now OK to make OF look special
instead.

If it is trivial to avoid that (and you seem to be arguing that it is), why
do we have to do it?

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
>> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> >> > But the point I'm making is that we are working towards *fixing* that,
>> >> > and *not* using DT-specific code in places where we should be using the
>> >> > generic APIs.
>> >>
>> >> What is the plan for fixing things here?  It's not obvious (at least to
>> >> me) that we don't want to have the subsystems having knowledge of how
>> >> they are bound to a specific firmware which is what you seem to imply
>> >> here.
>> >
>> > I don't know that there *is* a coherent plan here to address it all.
>> >
>> > Certainly, we *will* need subsystems to have firmware-specific
>> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
>> > describe GPIO, and properties which reference GPIO pins are intended to
>> > work through that — while in DT, properties which reference GPIO pins
>> > will have different contents. They'll be compatible at the driver
>> > level, in the sense that there's a call to get a given GPIO given the
>> > property name, but the subsystems *will* be doing different things
>> > behind the scenes.
>> >
>> > My plan, such as it is, is to go through the leaf-node drivers which
>> > almost definitely *should* be firmware-agnostic, and convert those. And
>> > then take stock of what we have left, and work out what, if anything,
>> > still needs to be done.
>>
>> Many cases are already agnostic in the drivers in terms of the *_get()
>> functions. Some are DT specific, but probably because those subsystems
>> are new and DT only. In any case, I don't think these 1 line changes
>> do anything to make doing conversions here harder.
>>
>> >> It seems like we're going to have to refactor these bits of code when
>> >> they get generalised anyway so I'm not sure that the additional cost
>> >> here is that big.
>> >
>> > That's an acceptable answer — "we're adding legacy code here but we
>> > know it's going to be refactored anyway". If that's true, all it takes
>> > is a note in the commit comment to that effect. That's different from
>> > having not thought about it :)
>>
>> Considering at one point we did create a fwnode based API, we did
>> think about it. Plus there was little input from ACPI folks as to
>> whether the change was even useful for ACPI case.
>
> Well, sorry, but who was asking whom, specifically?

You and linux-acpi have been copied on v2 and later of the entire
series I think.

> The underlying problem is present in ACPI too and we don't really have a good
> solution for it.  We might benefit from a common one if it existed.

The problem for DT is we don't generically know what are the
dependencies at a core level. We could know some or most dependencies
if phandles (links to other nodes) were typed, but they are not. If
the core had this information, we could simply control the device
creation to order probing. Instead, this information is encoded into
the bindings and binding parsing resides in the subsystems. That
parsing happens during probe of the client side and is done by the
subsystems (for common bindings). Since we already do the parsing at
this point, it is a convenient place to trigger the probe of the
dependency. Is ACPI going to be similar in this regard?

Fundamentally, it is a question of probe devices when their
dependencies are present or drivers ensure their dependencies are
ready. IIRC, init systems went thru a similar debate for service
dependencies.

>> In any case, we're talking about adding 1 line.
>
> But also about making the driver core slighly OF-centric.

How so? The one line is in DT binding parsing code in subsystems, not
driver core. The driver core change is we add every device (that
happened to be created by DT) to the deferred probe list, so they
don't probe right away.


> Sure, we need OF-specific code and ACPI-specific code wherever different
> handling is required, but doing that at the driver core level seems to be
> a bit of a stretch to me.
>
> Please note that we don't really have ACPI-specific calls in the driver core,
> although we might have added them long ago even before the OF stuff appeared
> in the kernel for the first time.  We didn't do that, (among other things)
> because we didn't want that particular firmware interface to appear special
> in any way and I'm not really sure why it is now OK to make OF look special
> instead.

I don't think DT is special and we avoid DT specific core changes as
much as possible. I think the difference is DT uses platform_device
and ACPI does not. It used to be separate, but got merged together
primarily to support the plethora of existing drivers. Anyway, that is
all outside of anything in this series.

> If it is trivial to avoid that (and you seem to be arguing that it is), why
> do we have to do it?

Sorry, I don't follow what "that" or "it" is.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
>> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> >> > But the point I'm making is that we are working towards *fixing* that,
>> >> > and *not* using DT-specific code in places where we should be using the
>> >> > generic APIs.
>> >>
>> >> What is the plan for fixing things here?  It's not obvious (at least to
>> >> me) that we don't want to have the subsystems having knowledge of how
>> >> they are bound to a specific firmware which is what you seem to imply
>> >> here.
>> >
>> > I don't know that there *is* a coherent plan here to address it all.
>> >
>> > Certainly, we *will* need subsystems to have firmware-specific
>> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
>> > describe GPIO, and properties which reference GPIO pins are intended to
>> > work through that — while in DT, properties which reference GPIO pins
>> > will have different contents. They'll be compatible at the driver
>> > level, in the sense that there's a call to get a given GPIO given the
>> > property name, but the subsystems *will* be doing different things
>> > behind the scenes.
>> >
>> > My plan, such as it is, is to go through the leaf-node drivers which
>> > almost definitely *should* be firmware-agnostic, and convert those. And
>> > then take stock of what we have left, and work out what, if anything,
>> > still needs to be done.
>>
>> Many cases are already agnostic in the drivers in terms of the *_get()
>> functions. Some are DT specific, but probably because those subsystems
>> are new and DT only. In any case, I don't think these 1 line changes
>> do anything to make doing conversions here harder.
>>
>> >> It seems like we're going to have to refactor these bits of code when
>> >> they get generalised anyway so I'm not sure that the additional cost
>> >> here is that big.
>> >
>> > That's an acceptable answer — "we're adding legacy code here but we
>> > know it's going to be refactored anyway". If that's true, all it takes
>> > is a note in the commit comment to that effect. That's different from
>> > having not thought about it :)
>>
>> Considering at one point we did create a fwnode based API, we did
>> think about it. Plus there was little input from ACPI folks as to
>> whether the change was even useful for ACPI case.
>
> Well, sorry, but who was asking whom, specifically?

You and linux-acpi have been copied on v2 and later of the entire
series I think.

> The underlying problem is present in ACPI too and we don't really have a good
> solution for it.  We might benefit from a common one if it existed.

The problem for DT is we don't generically know what are the
dependencies at a core level. We could know some or most dependencies
if phandles (links to other nodes) were typed, but they are not. If
the core had this information, we could simply control the device
creation to order probing. Instead, this information is encoded into
the bindings and binding parsing resides in the subsystems. That
parsing happens during probe of the client side and is done by the
subsystems (for common bindings). Since we already do the parsing at
this point, it is a convenient place to trigger the probe of the
dependency. Is ACPI going to be similar in this regard?

Fundamentally, it is a question of probe devices when their
dependencies are present or drivers ensure their dependencies are
ready. IIRC, init systems went thru a similar debate for service
dependencies.

>> In any case, we're talking about adding 1 line.
>
> But also about making the driver core slighly OF-centric.

How so? The one line is in DT binding parsing code in subsystems, not
driver core. The driver core change is we add every device (that
happened to be created by DT) to the deferred probe list, so they
don't probe right away.


> Sure, we need OF-specific code and ACPI-specific code wherever different
> handling is required, but doing that at the driver core level seems to be
> a bit of a stretch to me.
>
> Please note that we don't really have ACPI-specific calls in the driver core,
> although we might have added them long ago even before the OF stuff appeared
> in the kernel for the first time.  We didn't do that, (among other things)
> because we didn't want that particular firmware interface to appear special
> in any way and I'm not really sure why it is now OK to make OF look special
> instead.

I don't think DT is special and we avoid DT specific core changes as
much as possible. I think the difference is DT uses platform_device
and ACPI does not. It used to be separate, but got merged together
primarily to support the plethora of existing drivers. Anyway, that is
all outside of anything in this series.

> If it is trivial to avoid that (and you seem to be arguing that it is), why
> do we have to do it?

Sorry, I don't follow what "that" or "it" is.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrot=
e:
> On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
>> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> =
wrote:
>> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> >> > But the point I'm making is that we are working towards *fixing* th=
at,
>> >> > and *not* using DT-specific code in places where we should be using=
 the
>> >> > generic APIs.
>> >>
>> >> What is the plan for fixing things here?  It's not obvious (at least =
to
>> >> me) that we don't want to have the subsystems having knowledge of how
>> >> they are bound to a specific firmware which is what you seem to imply
>> >> here.
>> >
>> > I don't know that there *is* a coherent plan here to address it all.
>> >
>> > Certainly, we *will* need subsystems to have firmware-specific
>> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
>> > describe GPIO, and properties which reference GPIO pins are intended t=
o
>> > work through that =E2=80=94 while in DT, properties which reference GP=
IO pins
>> > will have different contents. They'll be compatible at the driver
>> > level, in the sense that there's a call to get a given GPIO given the
>> > property name, but the subsystems *will* be doing different things
>> > behind the scenes.
>> >
>> > My plan, such as it is, is to go through the leaf-node drivers which
>> > almost definitely *should* be firmware-agnostic, and convert those. An=
d
>> > then take stock of what we have left, and work out what, if anything,
>> > still needs to be done.
>>
>> Many cases are already agnostic in the drivers in terms of the *_get()
>> functions. Some are DT specific, but probably because those subsystems
>> are new and DT only. In any case, I don't think these 1 line changes
>> do anything to make doing conversions here harder.
>>
>> >> It seems like we're going to have to refactor these bits of code when
>> >> they get generalised anyway so I'm not sure that the additional cost
>> >> here is that big.
>> >
>> > That's an acceptable answer =E2=80=94 "we're adding legacy code here b=
ut we
>> > know it's going to be refactored anyway". If that's true, all it takes
>> > is a note in the commit comment to that effect. That's different from
>> > having not thought about it :)
>>
>> Considering at one point we did create a fwnode based API, we did
>> think about it. Plus there was little input from ACPI folks as to
>> whether the change was even useful for ACPI case.
>
> Well, sorry, but who was asking whom, specifically?

You and linux-acpi have been copied on v2 and later of the entire
series I think.

> The underlying problem is present in ACPI too and we don't really have a =
good
> solution for it.  We might benefit from a common one if it existed.

The problem for DT is we don't generically know what are the
dependencies at a core level. We could know some or most dependencies
if phandles (links to other nodes) were typed, but they are not. If
the core had this information, we could simply control the device
creation to order probing. Instead, this information is encoded into
the bindings and binding parsing resides in the subsystems. That
parsing happens during probe of the client side and is done by the
subsystems (for common bindings). Since we already do the parsing at
this point, it is a convenient place to trigger the probe of the
dependency. Is ACPI going to be similar in this regard?

Fundamentally, it is a question of probe devices when their
dependencies are present or drivers ensure their dependencies are
ready. IIRC, init systems went thru a similar debate for service
dependencies.

>> In any case, we're talking about adding 1 line.
>
> But also about making the driver core slighly OF-centric.

How so? The one line is in DT binding parsing code in subsystems, not
driver core. The driver core change is we add every device (that
happened to be created by DT) to the deferred probe list, so they
don't probe right away.


> Sure, we need OF-specific code and ACPI-specific code wherever different
> handling is required, but doing that at the driver core level seems to be
> a bit of a stretch to me.
>
> Please note that we don't really have ACPI-specific calls in the driver c=
ore,
> although we might have added them long ago even before the OF stuff appea=
red
> in the kernel for the first time.  We didn't do that, (among other things=
)
> because we didn't want that particular firmware interface to appear speci=
al
> in any way and I'm not really sure why it is now OK to make OF look speci=
al
> instead.

I don't think DT is special and we avoid DT specific core changes as
much as possible. I think the difference is DT uses platform_device
and ACPI does not. It used to be separate, but got merged together
primarily to support the plethora of existing drivers. Anyway, that is
all outside of anything in this series.

> If it is trivial to avoid that (and you seem to be arguing that it is), w=
hy
> do we have to do it?

Sorry, I don't follow what "that" or "it" is.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
>> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> >> > But the point I'm making is that we are working towards *fixing* that,
>> >> > and *not* using DT-specific code in places where we should be using the
>> >> > generic APIs.
>> >>
>> >> What is the plan for fixing things here?  It's not obvious (at least to
>> >> me) that we don't want to have the subsystems having knowledge of how
>> >> they are bound to a specific firmware which is what you seem to imply
>> >> here.
>> >
>> > I don't know that there *is* a coherent plan here to address it all.
>> >
>> > Certainly, we *will* need subsystems to have firmware-specific
>> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
>> > describe GPIO, and properties which reference GPIO pins are intended to
>> > work through that — while in DT, properties which reference GPIO pins
>> > will have different contents. They'll be compatible at the driver
>> > level, in the sense that there's a call to get a given GPIO given the
>> > property name, but the subsystems *will* be doing different things
>> > behind the scenes.
>> >
>> > My plan, such as it is, is to go through the leaf-node drivers which
>> > almost definitely *should* be firmware-agnostic, and convert those. And
>> > then take stock of what we have left, and work out what, if anything,
>> > still needs to be done.
>>
>> Many cases are already agnostic in the drivers in terms of the *_get()
>> functions. Some are DT specific, but probably because those subsystems
>> are new and DT only. In any case, I don't think these 1 line changes
>> do anything to make doing conversions here harder.
>>
>> >> It seems like we're going to have to refactor these bits of code when
>> >> they get generalised anyway so I'm not sure that the additional cost
>> >> here is that big.
>> >
>> > That's an acceptable answer — "we're adding legacy code here but we
>> > know it's going to be refactored anyway". If that's true, all it takes
>> > is a note in the commit comment to that effect. That's different from
>> > having not thought about it :)
>>
>> Considering at one point we did create a fwnode based API, we did
>> think about it. Plus there was little input from ACPI folks as to
>> whether the change was even useful for ACPI case.
>
> Well, sorry, but who was asking whom, specifically?

You and linux-acpi have been copied on v2 and later of the entire
series I think.

> The underlying problem is present in ACPI too and we don't really have a good
> solution for it.  We might benefit from a common one if it existed.

The problem for DT is we don't generically know what are the
dependencies at a core level. We could know some or most dependencies
if phandles (links to other nodes) were typed, but they are not. If
the core had this information, we could simply control the device
creation to order probing. Instead, this information is encoded into
the bindings and binding parsing resides in the subsystems. That
parsing happens during probe of the client side and is done by the
subsystems (for common bindings). Since we already do the parsing at
this point, it is a convenient place to trigger the probe of the
dependency. Is ACPI going to be similar in this regard?

Fundamentally, it is a question of probe devices when their
dependencies are present or drivers ensure their dependencies are
ready. IIRC, init systems went thru a similar debate for service
dependencies.

>> In any case, we're talking about adding 1 line.
>
> But also about making the driver core slighly OF-centric.

How so? The one line is in DT binding parsing code in subsystems, not
driver core. The driver core change is we add every device (that
happened to be created by DT) to the deferred probe list, so they
don't probe right away.


> Sure, we need OF-specific code and ACPI-specific code wherever different
> handling is required, but doing that at the driver core level seems to be
> a bit of a stretch to me.
>
> Please note that we don't really have ACPI-specific calls in the driver core,
> although we might have added them long ago even before the OF stuff appeared
> in the kernel for the first time.  We didn't do that, (among other things)
> because we didn't want that particular firmware interface to appear special
> in any way and I'm not really sure why it is now OK to make OF look special
> instead.

I don't think DT is special and we avoid DT specific core changes as
much as possible. I think the difference is DT uses platform_device
and ACPI does not. It used to be separate, but got merged together
primarily to support the plethora of existing drivers. Anyway, that is
all outside of anything in this series.

> If it is trivial to avoid that (and you seem to be arguing that it is), why
> do we have to do it?

Sorry, I don't follow what "that" or "it" is.

Rob

Re: [GIT PULL] On-demand device probing

[Alexandre Courbot]

On Tue, Oct 20, 2015 at 3:39 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote:
>> Hello,
>>
>> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
>> > It's a bit ironic that you've chosen GPIO as an example there.  The
>> > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
>> > gpio descriptor.  There's no of_* method.
>>
>> Without following all that fwnode discussion:
>> gpiod_get et al. should work for you here, doesn't it? It just takes a
>> struct device * and I'm happy with it.
>
> What if you don't have a struct device?  I had that problem recently
> when modifying the mvebu PCIe code.  The 'struct device' node doesn't
> contain the GPIOs, it's the PCIe controller.  Individual ports on the
> controller are described in DT as sub-nodes, and the sub-nodes can
> have a GPIO for card reset purposes.  These sub-nodes don't have a
> struct device.
>
> Right now, I'm having to do this to work around this issue:
>
>         reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, &flags);
>         if (reset_gpio == -EPROBE_DEFER) {
>                 ret = reset_gpio;
>                 goto err;
>         }
>
>         if (gpio_is_valid(reset_gpio)) {
>                 unsigned long gpio_flags;
>
>                 port->reset_name = devm_kasprintf(dev, GFP_KERNEL, "%s-reset",
>                                                   port->name);
>                 if (!port->reset_name) {
>                         ret = -ENOMEM;
>                         goto err;
>                 }
>
>                 if (flags & OF_GPIO_ACTIVE_LOW) {
>                         dev_info(dev, "%s: reset gpio is active low\n",
>                                  of_node_full_name(child));
>                         gpio_flags = GPIOF_ACTIVE_LOW |
>                                      GPIOF_OUT_INIT_LOW;
>                 } else {
>                         gpio_flags = GPIOF_OUT_INIT_HIGH;
>                 }
>
>                 ret = devm_gpio_request_one(dev, reset_gpio, gpio_flags,
>                                             port->reset_name);
>                 if (ret) {
>                         if (ret == -EPROBE_DEFER)
>                                 goto err;
>                         goto skip;
>                 }
>
>                 port->reset_gpio = gpio_to_desc(reset_gpio);
>         }
>
> Not nice, is it?  Not nice to have that in lots of drivers either.
>
> However, switching to use any of_* or fwnode_* thing also carries with
> it another problem: you can't control the name appearing in the
> allocation, so you end up with a bunch of GPIOs requested with a "reset"
> name - meaning you lose any identification of which port the GPIO was
> bound to.

There are a few holes in the gpiod API. I see two solutions here:

1) extend devm_get_gpiod_from_child() to take an optional name argument
2) add a function to explicitly change a GPIO's name

2) seems to be the most generic solution, would that do the trick?

(sorry for the off-topic)

Re: [GIT PULL] On-demand device probing

[Alexandre Courbot]

On Tue, Oct 20, 2015 at 3:39 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote:
>> Hello,
>>
>> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
>> > It's a bit ironic that you've chosen GPIO as an example there.  The
>> > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
>> > gpio descriptor.  There's no of_* method.
>>
>> Without following all that fwnode discussion:
>> gpiod_get et al. should work for you here, doesn't it? It just takes a
>> struct device * and I'm happy with it.
>
> What if you don't have a struct device?  I had that problem recently
> when modifying the mvebu PCIe code.  The 'struct device' node doesn't
> contain the GPIOs, it's the PCIe controller.  Individual ports on the
> controller are described in DT as sub-nodes, and the sub-nodes can
> have a GPIO for card reset purposes.  These sub-nodes don't have a
> struct device.
>
> Right now, I'm having to do this to work around this issue:
>
>         reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, &flags);
>         if (reset_gpio == -EPROBE_DEFER) {
>                 ret = reset_gpio;
>                 goto err;
>         }
>
>         if (gpio_is_valid(reset_gpio)) {
>                 unsigned long gpio_flags;
>
>                 port->reset_name = devm_kasprintf(dev, GFP_KERNEL, "%s-reset",
>                                                   port->name);
>                 if (!port->reset_name) {
>                         ret = -ENOMEM;
>                         goto err;
>                 }
>
>                 if (flags & OF_GPIO_ACTIVE_LOW) {
>                         dev_info(dev, "%s: reset gpio is active low\n",
>                                  of_node_full_name(child));
>                         gpio_flags = GPIOF_ACTIVE_LOW |
>                                      GPIOF_OUT_INIT_LOW;
>                 } else {
>                         gpio_flags = GPIOF_OUT_INIT_HIGH;
>                 }
>
>                 ret = devm_gpio_request_one(dev, reset_gpio, gpio_flags,
>                                             port->reset_name);
>                 if (ret) {
>                         if (ret == -EPROBE_DEFER)
>                                 goto err;
>                         goto skip;
>                 }
>
>                 port->reset_gpio = gpio_to_desc(reset_gpio);
>         }
>
> Not nice, is it?  Not nice to have that in lots of drivers either.
>
> However, switching to use any of_* or fwnode_* thing also carries with
> it another problem: you can't control the name appearing in the
> allocation, so you end up with a bunch of GPIOs requested with a "reset"
> name - meaning you lose any identification of which port the GPIO was
> bound to.

There are a few holes in the gpiod API. I see two solutions here:

1) extend devm_get_gpiod_from_child() to take an optional name argument
2) add a function to explicitly change a GPIO's name

2) seems to be the most generic solution, would that do the trick?

(sorry for the off-topic)

Re: [GIT PULL] On-demand device probing

[Alexandre Courbot]

On Tue, Oct 20, 2015 at 3:39 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-K=C3=B6nig wrote:
>> Hello,
>>
>> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote=
:
>> > It's a bit ironic that you've chosen GPIO as an example there.  The
>> > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
>> > gpio descriptor.  There's no of_* method.
>>
>> Without following all that fwnode discussion:
>> gpiod_get et al. should work for you here, doesn't it? It just takes a
>> struct device * and I'm happy with it.
>
> What if you don't have a struct device?  I had that problem recently
> when modifying the mvebu PCIe code.  The 'struct device' node doesn't
> contain the GPIOs, it's the PCIe controller.  Individual ports on the
> controller are described in DT as sub-nodes, and the sub-nodes can
> have a GPIO for card reset purposes.  These sub-nodes don't have a
> struct device.
>
> Right now, I'm having to do this to work around this issue:
>
>         reset_gpio =3D of_get_named_gpio_flags(child, "reset-gpios", 0, &=
flags);
>         if (reset_gpio =3D=3D -EPROBE_DEFER) {
>                 ret =3D reset_gpio;
>                 goto err;
>         }
>
>         if (gpio_is_valid(reset_gpio)) {
>                 unsigned long gpio_flags;
>
>                 port->reset_name =3D devm_kasprintf(dev, GFP_KERNEL, "%s-=
reset",
>                                                   port->name);
>                 if (!port->reset_name) {
>                         ret =3D -ENOMEM;
>                         goto err;
>                 }
>
>                 if (flags & OF_GPIO_ACTIVE_LOW) {
>                         dev_info(dev, "%s: reset gpio is active low\n",
>                                  of_node_full_name(child));
>                         gpio_flags =3D GPIOF_ACTIVE_LOW |
>                                      GPIOF_OUT_INIT_LOW;
>                 } else {
>                         gpio_flags =3D GPIOF_OUT_INIT_HIGH;
>                 }
>
>                 ret =3D devm_gpio_request_one(dev, reset_gpio, gpio_flags=
,
>                                             port->reset_name);
>                 if (ret) {
>                         if (ret =3D=3D -EPROBE_DEFER)
>                                 goto err;
>                         goto skip;
>                 }
>
>                 port->reset_gpio =3D gpio_to_desc(reset_gpio);
>         }
>
> Not nice, is it?  Not nice to have that in lots of drivers either.
>
> However, switching to use any of_* or fwnode_* thing also carries with
> it another problem: you can't control the name appearing in the
> allocation, so you end up with a bunch of GPIOs requested with a "reset"
> name - meaning you lose any identification of which port the GPIO was
> bound to.

There are a few holes in the gpiod API. I see two solutions here:

1) extend devm_get_gpiod_from_child() to take an optional name argument
2) add a function to explicitly change a GPIO's name

2) seems to be the most generic solution, would that do the trick?

(sorry for the off-topic)

Re: [GIT PULL] On-demand device probing

[Alexandre Courbot]

On Tue, Oct 20, 2015 at 3:39 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote:
>> Hello,
>>
>> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
>> > It's a bit ironic that you've chosen GPIO as an example there.  The
>> > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
>> > gpio descriptor.  There's no of_* method.
>>
>> Without following all that fwnode discussion:
>> gpiod_get et al. should work for you here, doesn't it? It just takes a
>> struct device * and I'm happy with it.
>
> What if you don't have a struct device?  I had that problem recently
> when modifying the mvebu PCIe code.  The 'struct device' node doesn't
> contain the GPIOs, it's the PCIe controller.  Individual ports on the
> controller are described in DT as sub-nodes, and the sub-nodes can
> have a GPIO for card reset purposes.  These sub-nodes don't have a
> struct device.
>
> Right now, I'm having to do this to work around this issue:
>
>         reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, &flags);
>         if (reset_gpio = -EPROBE_DEFER) {
>                 ret = reset_gpio;
>                 goto err;
>         }
>
>         if (gpio_is_valid(reset_gpio)) {
>                 unsigned long gpio_flags;
>
>                 port->reset_name = devm_kasprintf(dev, GFP_KERNEL, "%s-reset",
>                                                   port->name);
>                 if (!port->reset_name) {
>                         ret = -ENOMEM;
>                         goto err;
>                 }
>
>                 if (flags & OF_GPIO_ACTIVE_LOW) {
>                         dev_info(dev, "%s: reset gpio is active low\n",
>                                  of_node_full_name(child));
>                         gpio_flags = GPIOF_ACTIVE_LOW |
>                                      GPIOF_OUT_INIT_LOW;
>                 } else {
>                         gpio_flags = GPIOF_OUT_INIT_HIGH;
>                 }
>
>                 ret = devm_gpio_request_one(dev, reset_gpio, gpio_flags,
>                                             port->reset_name);
>                 if (ret) {
>                         if (ret = -EPROBE_DEFER)
>                                 goto err;
>                         goto skip;
>                 }
>
>                 port->reset_gpio = gpio_to_desc(reset_gpio);
>         }
>
> Not nice, is it?  Not nice to have that in lots of drivers either.
>
> However, switching to use any of_* or fwnode_* thing also carries with
> it another problem: you can't control the name appearing in the
> allocation, so you end up with a bunch of GPIOs requested with a "reset"
> name - meaning you lose any identification of which port the GPIO was
> bound to.

There are a few holes in the gpiod API. I see two solutions here:

1) extend devm_get_gpiod_from_child() to take an optional name argument
2) add a function to explicitly change a GPIO's name

2) seems to be the most generic solution, would that do the trick?

(sorry for the off-topic)

Re: gpiod API considerations [Was: [GIT PULL] On-demand device probing]

[Uwe Kleine-König]

Hello,

[trimming list of recipients considerably because of changed topic]

On Tue, Oct 20, 2015 at 08:47:21AM +0900, Alexandre Courbot wrote:
> On Tue, Oct 20, 2015 at 3:39 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote:
> >> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
> >> > It's a bit ironic that you've chosen GPIO as an example there.  The
> >> > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
> >> > gpio descriptor.  There's no of_* method.
> >>
> >> Without following all that fwnode discussion:
> >> gpiod_get et al. should work for you here, doesn't it? It just takes a
> >> struct device * and I'm happy with it.
> >
> > What if you don't have a struct device?  I had that problem recently
> > when modifying the mvebu PCIe code.  The 'struct device' node doesn't
> > contain the GPIOs, it's the PCIe controller.  Individual ports on the
> > controller are described in DT as sub-nodes, and the sub-nodes can
> > have a GPIO for card reset purposes.  These sub-nodes don't have a
> > struct device.
> >
> > Right now, I'm having to do this to work around this issue:
> >
> >         reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, &flags);
> >         if (reset_gpio == -EPROBE_DEFER) {
> >                 ret = reset_gpio;
> >                 goto err;
> >         }
> >
> >         if (gpio_is_valid(reset_gpio)) {
> >                 unsigned long gpio_flags;
> >
> >                 port->reset_name = devm_kasprintf(dev, GFP_KERNEL, "%s-reset",
> >                                                   port->name);
> >                 if (!port->reset_name) {
> >                         ret = -ENOMEM;
> >                         goto err;
> >                 }
> >
> >                 if (flags & OF_GPIO_ACTIVE_LOW) {
> >                         dev_info(dev, "%s: reset gpio is active low\n",
> >                                  of_node_full_name(child));
> >                         gpio_flags = GPIOF_ACTIVE_LOW |
> >                                      GPIOF_OUT_INIT_LOW;
> >                 } else {
> >                         gpio_flags = GPIOF_OUT_INIT_HIGH;
> >                 }
> >
> >                 ret = devm_gpio_request_one(dev, reset_gpio, gpio_flags,
> >                                             port->reset_name);
> >                 if (ret) {
> >                         if (ret == -EPROBE_DEFER)
> >                                 goto err;
> >                         goto skip;
> >                 }
> >
> >                 port->reset_gpio = gpio_to_desc(reset_gpio);
> >         }
> >
> > Not nice, is it?  Not nice to have that in lots of drivers either.
> >
> > However, switching to use any of_* or fwnode_* thing also carries with
> > it another problem: you can't control the name appearing in the
> > allocation, so you end up with a bunch of GPIOs requested with a "reset"
> > name - meaning you lose any identification of which port the GPIO was
> > bound to.
> 
> There are a few holes in the gpiod API. I see two solutions here:
> 
> 1) extend devm_get_gpiod_from_child() to take an optional name argument
> 2) add a function to explicitly change a GPIO's name
> 
> 2) seems to be the most generic solution, would that do the trick?

I would prefer 1) without "optional". A third alternative is to add at
least dev_name(dev) and maybe index to the name where applicable. Also
note that gpiod_request is called with label=NULL (in
fwnode_get_named_gpiod which is used in devm_get_gpiod_from_child), so
/sys/kernel/debug/gpio doesn't even contain "reset". I only see question
marks (using v4.3-rc5).

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> wrote:
> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> >> > But the point I'm making is that we are working towards *fixing* that,
> >> >> > and *not* using DT-specific code in places where we should be using the
> >> >> > generic APIs.
> >> >>
> >> >> What is the plan for fixing things here?  It's not obvious (at least to
> >> >> me) that we don't want to have the subsystems having knowledge of how
> >> >> they are bound to a specific firmware which is what you seem to imply
> >> >> here.
> >> >
> >> > I don't know that there *is* a coherent plan here to address it all.
> >> >
> >> > Certainly, we *will* need subsystems to have firmware-specific
> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> >> > describe GPIO, and properties which reference GPIO pins are intended to
> >> > work through that — while in DT, properties which reference GPIO pins
> >> > will have different contents. They'll be compatible at the driver
> >> > level, in the sense that there's a call to get a given GPIO given the
> >> > property name, but the subsystems *will* be doing different things
> >> > behind the scenes.
> >> >
> >> > My plan, such as it is, is to go through the leaf-node drivers which
> >> > almost definitely *should* be firmware-agnostic, and convert those. And
> >> > then take stock of what we have left, and work out what, if anything,
> >> > still needs to be done.
> >>
> >> Many cases are already agnostic in the drivers in terms of the *_get()
> >> functions. Some are DT specific, but probably because those subsystems
> >> are new and DT only. In any case, I don't think these 1 line changes
> >> do anything to make doing conversions here harder.
> >>
> >> >> It seems like we're going to have to refactor these bits of code when
> >> >> they get generalised anyway so I'm not sure that the additional cost
> >> >> here is that big.
> >> >
> >> > That's an acceptable answer — "we're adding legacy code here but we
> >> > know it's going to be refactored anyway". If that's true, all it takes
> >> > is a note in the commit comment to that effect. That's different from
> >> > having not thought about it :)
> >>
> >> Considering at one point we did create a fwnode based API, we did
> >> think about it. Plus there was little input from ACPI folks as to
> >> whether the change was even useful for ACPI case.
> >
> > Well, sorry, but who was asking whom, specifically?
> 
> You and linux-acpi have been copied on v2 and later of the entire
> series I think.

Yes, but it wasn't like a direct request, say "We need your input, so can you
please have a look and BTW we want this in 4.4, so please do it ASAP".  In
which case I'd prioritize that before other things I needed to take care of.

> > The underlying problem is present in ACPI too and we don't really have a good
> > solution for it.  We might benefit from a common one if it existed.
> 
> The problem for DT is we don't generically know what are the
> dependencies at a core level. We could know some or most dependencies
> if phandles (links to other nodes) were typed, but they are not. If
> the core had this information, we could simply control the device
> creation to order probing. Instead, this information is encoded into
> the bindings and binding parsing resides in the subsystems. That
> parsing happens during probe of the client side and is done by the
> subsystems (for common bindings). Since we already do the parsing at
> this point, it is a convenient place to trigger the probe of the
> dependency. Is ACPI going to be similar in this regard?

It is similar in some ways.  For example, if a device's functionality depends
on an I2C resource (connection), the core doesn't know that at the device
creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.

There is a _DEP object in ACPI that can be used by firmware to tell the OS
about those dependencies, but there's no way in the driver core to use that
information anyway today.

> Fundamentally, it is a question of probe devices when their
> dependencies are present or drivers ensure their dependencies are
> ready. IIRC, init systems went thru a similar debate for service
> dependencies.

The probe ordering is not the entire picture, though.

Even if you get the probe ordering right, the problem is going to show up in
multiple other places: system suspend/resume, runtime PM, system shutdown,
unbinding of drivers.  In all of those cases it is necessary to handle things
in a specific order if there is a dependency.

> >> In any case, we're talking about adding 1 line.
> >
> > But also about making the driver core slighly OF-centric.
> 
> How so? The one line is in DT binding parsing code in subsystems, not
> driver core. The driver core change is we add every device (that
> happened to be created by DT) to the deferred probe list, so they
> don't probe right away.

The "that happened to be created by DT" part is of concern here.  What is there
that makes DT special in that respect?  Why shouldn't that be applicable to
devices created by the ACPI core, for example, or by a board file or something
else?

> > Sure, we need OF-specific code and ACPI-specific code wherever different
> > handling is required, but doing that at the driver core level seems to be
> > a bit of a stretch to me.
> >
> > Please note that we don't really have ACPI-specific calls in the driver core,
> > although we might have added them long ago even before the OF stuff appeared
> > in the kernel for the first time.  We didn't do that, (among other things)
> > because we didn't want that particular firmware interface to appear special
> > in any way and I'm not really sure why it is now OK to make OF look special
> > instead.
> 
> I don't think DT is special and we avoid DT specific core changes as
> much as possible. I think the difference is DT uses platform_device
> and ACPI does not.

ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
platform devices by default now.

Or do you means something else here?

> It used to be separate, but got merged together primarily to support the
> plethora of existing drivers. Anyway, that is all outside of anything in this
> series.

It explains the context of the series, so it is useful to talk about IMO.

> 
> > If it is trivial to avoid that (and you seem to be arguing that it is), why
> > do we have to do it?
> 
> Sorry, I don't follow what "that" or "it" is.

OK, so maybe I misunderstood you, sorry about that.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> >> > But the point I'm making is that we are working towards *fixing* that,
> >> >> > and *not* using DT-specific code in places where we should be using the
> >> >> > generic APIs.
> >> >>
> >> >> What is the plan for fixing things here?  It's not obvious (at least to
> >> >> me) that we don't want to have the subsystems having knowledge of how
> >> >> they are bound to a specific firmware which is what you seem to imply
> >> >> here.
> >> >
> >> > I don't know that there *is* a coherent plan here to address it all.
> >> >
> >> > Certainly, we *will* need subsystems to have firmware-specific
> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> >> > describe GPIO, and properties which reference GPIO pins are intended to
> >> > work through that — while in DT, properties which reference GPIO pins
> >> > will have different contents. They'll be compatible at the driver
> >> > level, in the sense that there's a call to get a given GPIO given the
> >> > property name, but the subsystems *will* be doing different things
> >> > behind the scenes.
> >> >
> >> > My plan, such as it is, is to go through the leaf-node drivers which
> >> > almost definitely *should* be firmware-agnostic, and convert those. And
> >> > then take stock of what we have left, and work out what, if anything,
> >> > still needs to be done.
> >>
> >> Many cases are already agnostic in the drivers in terms of the *_get()
> >> functions. Some are DT specific, but probably because those subsystems
> >> are new and DT only. In any case, I don't think these 1 line changes
> >> do anything to make doing conversions here harder.
> >>
> >> >> It seems like we're going to have to refactor these bits of code when
> >> >> they get generalised anyway so I'm not sure that the additional cost
> >> >> here is that big.
> >> >
> >> > That's an acceptable answer — "we're adding legacy code here but we
> >> > know it's going to be refactored anyway". If that's true, all it takes
> >> > is a note in the commit comment to that effect. That's different from
> >> > having not thought about it :)
> >>
> >> Considering at one point we did create a fwnode based API, we did
> >> think about it. Plus there was little input from ACPI folks as to
> >> whether the change was even useful for ACPI case.
> >
> > Well, sorry, but who was asking whom, specifically?
> 
> You and linux-acpi have been copied on v2 and later of the entire
> series I think.

Yes, but it wasn't like a direct request, say "We need your input, so can you
please have a look and BTW we want this in 4.4, so please do it ASAP".  In
which case I'd prioritize that before other things I needed to take care of.

> > The underlying problem is present in ACPI too and we don't really have a good
> > solution for it.  We might benefit from a common one if it existed.
> 
> The problem for DT is we don't generically know what are the
> dependencies at a core level. We could know some or most dependencies
> if phandles (links to other nodes) were typed, but they are not. If
> the core had this information, we could simply control the device
> creation to order probing. Instead, this information is encoded into
> the bindings and binding parsing resides in the subsystems. That
> parsing happens during probe of the client side and is done by the
> subsystems (for common bindings). Since we already do the parsing at
> this point, it is a convenient place to trigger the probe of the
> dependency. Is ACPI going to be similar in this regard?

It is similar in some ways.  For example, if a device's functionality depends
on an I2C resource (connection), the core doesn't know that at the device
creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.

There is a _DEP object in ACPI that can be used by firmware to tell the OS
about those dependencies, but there's no way in the driver core to use that
information anyway today.

> Fundamentally, it is a question of probe devices when their
> dependencies are present or drivers ensure their dependencies are
> ready. IIRC, init systems went thru a similar debate for service
> dependencies.

The probe ordering is not the entire picture, though.

Even if you get the probe ordering right, the problem is going to show up in
multiple other places: system suspend/resume, runtime PM, system shutdown,
unbinding of drivers.  In all of those cases it is necessary to handle things
in a specific order if there is a dependency.

> >> In any case, we're talking about adding 1 line.
> >
> > But also about making the driver core slighly OF-centric.
> 
> How so? The one line is in DT binding parsing code in subsystems, not
> driver core. The driver core change is we add every device (that
> happened to be created by DT) to the deferred probe list, so they
> don't probe right away.

The "that happened to be created by DT" part is of concern here.  What is there
that makes DT special in that respect?  Why shouldn't that be applicable to
devices created by the ACPI core, for example, or by a board file or something
else?

> > Sure, we need OF-specific code and ACPI-specific code wherever different
> > handling is required, but doing that at the driver core level seems to be
> > a bit of a stretch to me.
> >
> > Please note that we don't really have ACPI-specific calls in the driver core,
> > although we might have added them long ago even before the OF stuff appeared
> > in the kernel for the first time.  We didn't do that, (among other things)
> > because we didn't want that particular firmware interface to appear special
> > in any way and I'm not really sure why it is now OK to make OF look special
> > instead.
> 
> I don't think DT is special and we avoid DT specific core changes as
> much as possible. I think the difference is DT uses platform_device
> and ACPI does not.

ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
platform devices by default now.

Or do you means something else here?

> It used to be separate, but got merged together primarily to support the
> plethora of existing drivers. Anyway, that is all outside of anything in this
> series.

It explains the context of the series, so it is useful to talk about IMO.

> 
> > If it is trivial to avoid that (and you seem to be arguing that it is), why
> > do we have to do it?
> 
> Sorry, I don't follow what "that" or "it" is.

OK, so maybe I misunderstood you, sorry about that.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net=
> wrote:
> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead=
.org> wrote:
> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> >> > But the point I'm making is that we are working towards *fixi=
ng* that,
> >> >> > and *not* using DT-specific code in places where we should be=
 using the
> >> >> > generic APIs.
> >> >>
> >> >> What is the plan for fixing things here?  It's not obvious (at =
least to
> >> >> me) that we don't want to have the subsystems having knowledge =
of how
> >> >> they are bound to a specific firmware which is what you seem to=
 imply
> >> >> here.
> >> >
> >> > I don't know that there *is* a coherent plan here to address it =
all.
> >> >
> >> > Certainly, we *will* need subsystems to have firmware-specific
> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a w=
ay to
> >> > describe GPIO, and properties which reference GPIO pins are inte=
nded to
> >> > work through that =E2=80=94 while in DT, properties which refere=
nce GPIO pins
> >> > will have different contents. They'll be compatible at the drive=
r
> >> > level, in the sense that there's a call to get a given GPIO give=
n the
> >> > property name, but the subsystems *will* be doing different thin=
gs
> >> > behind the scenes.
> >> >
> >> > My plan, such as it is, is to go through the leaf-node drivers w=
hich
> >> > almost definitely *should* be firmware-agnostic, and convert tho=
se. And
> >> > then take stock of what we have left, and work out what, if anyt=
hing,
> >> > still needs to be done.
> >>
> >> Many cases are already agnostic in the drivers in terms of the *_g=
et()
> >> functions. Some are DT specific, but probably because those subsys=
tems
> >> are new and DT only. In any case, I don't think these 1 line chang=
es
> >> do anything to make doing conversions here harder.
> >>
> >> >> It seems like we're going to have to refactor these bits of cod=
e when
> >> >> they get generalised anyway so I'm not sure that the additional=
 cost
> >> >> here is that big.
> >> >
> >> > That's an acceptable answer =E2=80=94 "we're adding legacy code =
here but we
> >> > know it's going to be refactored anyway". If that's true, all it=
 takes
> >> > is a note in the commit comment to that effect. That's different=
 from
> >> > having not thought about it :)
> >>
> >> Considering at one point we did create a fwnode based API, we did
> >> think about it. Plus there was little input from ACPI folks as to
> >> whether the change was even useful for ACPI case.
> >
> > Well, sorry, but who was asking whom, specifically?
>=20
> You and linux-acpi have been copied on v2 and later of the entire
> series I think.

Yes, but it wasn't like a direct request, say "We need your input, so c=
an you
please have a look and BTW we want this in 4.4, so please do it ASAP". =
 In
which case I'd prioritize that before other things I needed to take car=
e of.

> > The underlying problem is present in ACPI too and we don't really h=
ave a good
> > solution for it.  We might benefit from a common one if it existed.=

>=20
> The problem for DT is we don't generically know what are the
> dependencies at a core level. We could know some or most dependencies=

> if phandles (links to other nodes) were typed, but they are not. If
> the core had this information, we could simply control the device
> creation to order probing. Instead, this information is encoded into
> the bindings and binding parsing resides in the subsystems. That
> parsing happens during probe of the client side and is done by the
> subsystems (for common bindings). Since we already do the parsing at
> this point, it is a convenient place to trigger the probe of the
> dependency. Is ACPI going to be similar in this regard?

It is similar in some ways.  For example, if a device's functionality d=
epends
on an I2C resource (connection), the core doesn't know that at the devi=
ce
creation time at least in some cases.  Same for GPIO, SPI, DMA engines =
etc.

There is a _DEP object in ACPI that can be used by firmware to tell the=
 OS
about those dependencies, but there's no way in the driver core to use =
that
information anyway today.

> Fundamentally, it is a question of probe devices when their
> dependencies are present or drivers ensure their dependencies are
> ready. IIRC, init systems went thru a similar debate for service
> dependencies.

The probe ordering is not the entire picture, though.

Even if you get the probe ordering right, the problem is going to show =
up in
multiple other places: system suspend/resume, runtime PM, system shutdo=
wn,
unbinding of drivers.  In all of those cases it is necessary to handle =
things
in a specific order if there is a dependency.

> >> In any case, we're talking about adding 1 line.
> >
> > But also about making the driver core slighly OF-centric.
>=20
> How so? The one line is in DT binding parsing code in subsystems, not=

> driver core. The driver core change is we add every device (that
> happened to be created by DT) to the deferred probe list, so they
> don't probe right away.

The "that happened to be created by DT" part is of concern here.  What =
is there
that makes DT special in that respect?  Why shouldn't that be applicabl=
e to
devices created by the ACPI core, for example, or by a board file or so=
mething
else?

> > Sure, we need OF-specific code and ACPI-specific code wherever diff=
erent
> > handling is required, but doing that at the driver core level seems=
 to be
> > a bit of a stretch to me.
> >
> > Please note that we don't really have ACPI-specific calls in the dr=
iver core,
> > although we might have added them long ago even before the OF stuff=
 appeared
> > in the kernel for the first time.  We didn't do that, (among other =
things)
> > because we didn't want that particular firmware interface to appear=
 special
> > in any way and I'm not really sure why it is now OK to make OF look=
 special
> > instead.
>=20
> I don't think DT is special and we avoid DT specific core changes as
> much as possible. I think the difference is DT uses platform_device
> and ACPI does not.

ACPI uses platform devices too.  In fact, ACPI device objects are enume=
rated as
platform devices by default now.

Or do you means something else here?

> It used to be separate, but got merged together primarily to support =
the
> plethora of existing drivers. Anyway, that is all outside of anything=
 in this
> series.

It explains the context of the series, so it is useful to talk about IM=
O.

>=20
> > If it is trivial to avoid that (and you seem to be arguing that it =
is), why
> > do we have to do it?
>=20
> Sorry, I don't follow what "that" or "it" is.

OK, so maybe I misunderstood you, sorry about that.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> >> > But the point I'm making is that we are working towards *fixing* that,
> >> >> > and *not* using DT-specific code in places where we should be using the
> >> >> > generic APIs.
> >> >>
> >> >> What is the plan for fixing things here?  It's not obvious (at least to
> >> >> me) that we don't want to have the subsystems having knowledge of how
> >> >> they are bound to a specific firmware which is what you seem to imply
> >> >> here.
> >> >
> >> > I don't know that there *is* a coherent plan here to address it all.
> >> >
> >> > Certainly, we *will* need subsystems to have firmware-specific
> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> >> > describe GPIO, and properties which reference GPIO pins are intended to
> >> > work through that — while in DT, properties which reference GPIO pins
> >> > will have different contents. They'll be compatible at the driver
> >> > level, in the sense that there's a call to get a given GPIO given the
> >> > property name, but the subsystems *will* be doing different things
> >> > behind the scenes.
> >> >
> >> > My plan, such as it is, is to go through the leaf-node drivers which
> >> > almost definitely *should* be firmware-agnostic, and convert those. And
> >> > then take stock of what we have left, and work out what, if anything,
> >> > still needs to be done.
> >>
> >> Many cases are already agnostic in the drivers in terms of the *_get()
> >> functions. Some are DT specific, but probably because those subsystems
> >> are new and DT only. In any case, I don't think these 1 line changes
> >> do anything to make doing conversions here harder.
> >>
> >> >> It seems like we're going to have to refactor these bits of code when
> >> >> they get generalised anyway so I'm not sure that the additional cost
> >> >> here is that big.
> >> >
> >> > That's an acceptable answer — "we're adding legacy code here but we
> >> > know it's going to be refactored anyway". If that's true, all it takes
> >> > is a note in the commit comment to that effect. That's different from
> >> > having not thought about it :)
> >>
> >> Considering at one point we did create a fwnode based API, we did
> >> think about it. Plus there was little input from ACPI folks as to
> >> whether the change was even useful for ACPI case.
> >
> > Well, sorry, but who was asking whom, specifically?
> 
> You and linux-acpi have been copied on v2 and later of the entire
> series I think.

Yes, but it wasn't like a direct request, say "We need your input, so can you
please have a look and BTW we want this in 4.4, so please do it ASAP".  In
which case I'd prioritize that before other things I needed to take care of.

> > The underlying problem is present in ACPI too and we don't really have a good
> > solution for it.  We might benefit from a common one if it existed.
> 
> The problem for DT is we don't generically know what are the
> dependencies at a core level. We could know some or most dependencies
> if phandles (links to other nodes) were typed, but they are not. If
> the core had this information, we could simply control the device
> creation to order probing. Instead, this information is encoded into
> the bindings and binding parsing resides in the subsystems. That
> parsing happens during probe of the client side and is done by the
> subsystems (for common bindings). Since we already do the parsing at
> this point, it is a convenient place to trigger the probe of the
> dependency. Is ACPI going to be similar in this regard?

It is similar in some ways.  For example, if a device's functionality depends
on an I2C resource (connection), the core doesn't know that at the device
creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.

There is a _DEP object in ACPI that can be used by firmware to tell the OS
about those dependencies, but there's no way in the driver core to use that
information anyway today.

> Fundamentally, it is a question of probe devices when their
> dependencies are present or drivers ensure their dependencies are
> ready. IIRC, init systems went thru a similar debate for service
> dependencies.

The probe ordering is not the entire picture, though.

Even if you get the probe ordering right, the problem is going to show up in
multiple other places: system suspend/resume, runtime PM, system shutdown,
unbinding of drivers.  In all of those cases it is necessary to handle things
in a specific order if there is a dependency.

> >> In any case, we're talking about adding 1 line.
> >
> > But also about making the driver core slighly OF-centric.
> 
> How so? The one line is in DT binding parsing code in subsystems, not
> driver core. The driver core change is we add every device (that
> happened to be created by DT) to the deferred probe list, so they
> don't probe right away.

The "that happened to be created by DT" part is of concern here.  What is there
that makes DT special in that respect?  Why shouldn't that be applicable to
devices created by the ACPI core, for example, or by a board file or something
else?

> > Sure, we need OF-specific code and ACPI-specific code wherever different
> > handling is required, but doing that at the driver core level seems to be
> > a bit of a stretch to me.
> >
> > Please note that we don't really have ACPI-specific calls in the driver core,
> > although we might have added them long ago even before the OF stuff appeared
> > in the kernel for the first time.  We didn't do that, (among other things)
> > because we didn't want that particular firmware interface to appear special
> > in any way and I'm not really sure why it is now OK to make OF look special
> > instead.
> 
> I don't think DT is special and we avoid DT specific core changes as
> much as possible. I think the difference is DT uses platform_device
> and ACPI does not.

ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
platform devices by default now.

Or do you means something else here?

> It used to be separate, but got merged together primarily to support the
> plethora of existing drivers. Anyway, that is all outside of anything in this
> series.

It explains the context of the series, so it is useful to talk about IMO.

> 
> > If it is trivial to avoid that (and you seem to be arguing that it is), why
> > do we have to do it?
> 
> Sorry, I don't follow what "that" or "it" is.

OK, so maybe I misunderstood you, sorry about that.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 2757 bytes --]

On Mon, 2015-10-19 at 16:43 +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> > I don't know that there *is* a coherent plan here to address it
> > all.
> > 
> > Certainly, we *will* need subsystems to have firmware-specific
> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way
> > to
> > describe GPIO, and properties which reference GPIO pins are
> > intended to
> > work through that — while in DT, properties which reference GPIO
> > pins
> > will have different contents. They'll be compatible at the driver
> > level, in the sense that there's a call to get a given GPIO given
> > the
> > property name, but the subsystems *will* be doing different things
> > behind the scenes.
> 
> It's a bit ironic that you've chosen GPIO as an example there.  The
> "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
> gpio descriptor.  There's no of_* method.

I think that part is already being worked on, but...

> If ACPI already handles GPIOs internally, then I'm left wondering
> why GPIO descriptor stuff went down the fwnode route at all - it
> seems rather pointless in this case, 

ACPI already had a way for a given device to say that it uses certain
other GPIOs. But until we had device properties in ACPI, it could say
*what* it used them for. So sure, we could say that we used GPIO#15
from <this> controller and GPIOs #27 and #31 from <that> controller.
But there was no way to say that the former was the shotdown pin and
the latter was the reset pin.

While a GPIO property in DT will contain a phandle and basically be a
complete reference to find the pin you're after, the same property
represented in ACPI will just be an index into the resources that ACPI
could already refer to.

So referring to the example in Documentation/acpi/gpio-properties.txt:

      Name (_CRS, ResourceTemplate ()
      {
          GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                  "\\_SB.GPO0", 0, ResourceConsumer) {15}
          GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                  "\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
      })

That part, ACPI already had. But..

      Name (_DSD, Package ()
      {
          ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
          Package ()
          {
              Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
              Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
          }
      })

...this part is new, and allows us the full flexibility of device
properties. And the appropriate gpiod_get* function is supposed to
transparently work on either DT or ACPI.


-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [GIT PULL] On-demand device probing

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 2757 bytes --]

On Mon, 2015-10-19 at 16:43 +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> > I don't know that there *is* a coherent plan here to address it
> > all.
> > 
> > Certainly, we *will* need subsystems to have firmware-specific
> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way
> > to
> > describe GPIO, and properties which reference GPIO pins are
> > intended to
> > work through that — while in DT, properties which reference GPIO
> > pins
> > will have different contents. They'll be compatible at the driver
> > level, in the sense that there's a call to get a given GPIO given
> > the
> > property name, but the subsystems *will* be doing different things
> > behind the scenes.
> 
> It's a bit ironic that you've chosen GPIO as an example there.  The
> "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
> gpio descriptor.  There's no of_* method.

I think that part is already being worked on, but...

> If ACPI already handles GPIOs internally, then I'm left wondering
> why GPIO descriptor stuff went down the fwnode route at all - it
> seems rather pointless in this case, 

ACPI already had a way for a given device to say that it uses certain
other GPIOs. But until we had device properties in ACPI, it could say
*what* it used them for. So sure, we could say that we used GPIO#15
from <this> controller and GPIOs #27 and #31 from <that> controller.
But there was no way to say that the former was the shotdown pin and
the latter was the reset pin.

While a GPIO property in DT will contain a phandle and basically be a
complete reference to find the pin you're after, the same property
represented in ACPI will just be an index into the resources that ACPI
could already refer to.

So referring to the example in Documentation/acpi/gpio-properties.txt:

      Name (_CRS, ResourceTemplate ()
      {
          GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                  "\\_SB.GPO0", 0, ResourceConsumer) {15}
          GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                  "\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
      })

That part, ACPI already had. But..

      Name (_DSD, Package ()
      {
          ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
          Package ()
          {
              Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
              Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
          }
      })

...this part is new, and allows us the full flexibility of device
properties. And the appropriate gpiod_get* function is supposed to
transparently work on either DT or ACPI.


-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [GIT PULL] On-demand device probing

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 2757 bytes --]

On Mon, 2015-10-19 at 16:43 +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> > I don't know that there *is* a coherent plan here to address it
> > all.
> > 
> > Certainly, we *will* need subsystems to have firmware-specific
> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way
> > to
> > describe GPIO, and properties which reference GPIO pins are
> > intended to
> > work through that — while in DT, properties which reference GPIO
> > pins
> > will have different contents. They'll be compatible at the driver
> > level, in the sense that there's a call to get a given GPIO given
> > the
> > property name, but the subsystems *will* be doing different things
> > behind the scenes.
> 
> It's a bit ironic that you've chosen GPIO as an example there.  The
> "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the
> gpio descriptor.  There's no of_* method.

I think that part is already being worked on, but...

> If ACPI already handles GPIOs internally, then I'm left wondering
> why GPIO descriptor stuff went down the fwnode route at all - it
> seems rather pointless in this case, 

ACPI already had a way for a given device to say that it uses certain
other GPIOs. But until we had device properties in ACPI, it could say
*what* it used them for. So sure, we could say that we used GPIO#15
from <this> controller and GPIOs #27 and #31 from <that> controller.
But there was no way to say that the former was the shotdown pin and
the latter was the reset pin.

While a GPIO property in DT will contain a phandle and basically be a
complete reference to find the pin you're after, the same property
represented in ACPI will just be an index into the resources that ACPI
could already refer to.

So referring to the example in Documentation/acpi/gpio-properties.txt:

      Name (_CRS, ResourceTemplate ()
      {
          GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                  "\\_SB.GPO0", 0, ResourceConsumer) {15}
          GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
                  "\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
      })

That part, ACPI already had. But..

      Name (_DSD, Package ()
      {
          ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
          Package ()
          {
              Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
              Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
          }
      })

...this part is new, and allows us the full flexibility of device
properties. And the appropriate gpiod_get* function is supposed to
transparently work on either DT or ACPI.


-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
>> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
>> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> >> >> > But the point I'm making is that we are working towards *fixing* that,
>> >> >> > and *not* using DT-specific code in places where we should be using the
>> >> >> > generic APIs.
>> >> >>
>> >> >> What is the plan for fixing things here?  It's not obvious (at least to
>> >> >> me) that we don't want to have the subsystems having knowledge of how
>> >> >> they are bound to a specific firmware which is what you seem to imply
>> >> >> here.
>> >> >
>> >> > I don't know that there *is* a coherent plan here to address it all.
>> >> >
>> >> > Certainly, we *will* need subsystems to have firmware-specific
>> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
>> >> > describe GPIO, and properties which reference GPIO pins are intended to
>> >> > work through that — while in DT, properties which reference GPIO pins
>> >> > will have different contents. They'll be compatible at the driver
>> >> > level, in the sense that there's a call to get a given GPIO given the
>> >> > property name, but the subsystems *will* be doing different things
>> >> > behind the scenes.
>> >> >
>> >> > My plan, such as it is, is to go through the leaf-node drivers which
>> >> > almost definitely *should* be firmware-agnostic, and convert those. And
>> >> > then take stock of what we have left, and work out what, if anything,
>> >> > still needs to be done.
>> >>
>> >> Many cases are already agnostic in the drivers in terms of the *_get()
>> >> functions. Some are DT specific, but probably because those subsystems
>> >> are new and DT only. In any case, I don't think these 1 line changes
>> >> do anything to make doing conversions here harder.
>> >>
>> >> >> It seems like we're going to have to refactor these bits of code when
>> >> >> they get generalised anyway so I'm not sure that the additional cost
>> >> >> here is that big.
>> >> >
>> >> > That's an acceptable answer — "we're adding legacy code here but we
>> >> > know it's going to be refactored anyway". If that's true, all it takes
>> >> > is a note in the commit comment to that effect. That's different from
>> >> > having not thought about it :)
>> >>
>> >> Considering at one point we did create a fwnode based API, we did
>> >> think about it. Plus there was little input from ACPI folks as to
>> >> whether the change was even useful for ACPI case.
>> >
>> > Well, sorry, but who was asking whom, specifically?
>>
>> You and linux-acpi have been copied on v2 and later of the entire
>> series I think.
>
> Yes, but it wasn't like a direct request, say "We need your input, so can you
> please have a look and BTW we want this in 4.4, so please do it ASAP".  In
> which case I'd prioritize that before other things I needed to take care of.

Fair enough. Can you please review and comment on v7 of the series? We
can discuss at KS as well.

>> > The underlying problem is present in ACPI too and we don't really have a good
>> > solution for it.  We might benefit from a common one if it existed.
>>
>> The problem for DT is we don't generically know what are the
>> dependencies at a core level. We could know some or most dependencies
>> if phandles (links to other nodes) were typed, but they are not. If
>> the core had this information, we could simply control the device
>> creation to order probing. Instead, this information is encoded into
>> the bindings and binding parsing resides in the subsystems. That
>> parsing happens during probe of the client side and is done by the
>> subsystems (for common bindings). Since we already do the parsing at
>> this point, it is a convenient place to trigger the probe of the
>> dependency. Is ACPI going to be similar in this regard?
>
> It is similar in some ways.  For example, if a device's functionality depends
> on an I2C resource (connection), the core doesn't know that at the device
> creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.

So you will need to create devices, defer their probing and then probe
on demand as well unless you have other ideas how you would do it.

> There is a _DEP object in ACPI that can be used by firmware to tell the OS
> about those dependencies, but there's no way in the driver core to use that
> information anyway today.

I would think that the equivalent function for ACPI to of_device_probe
could process these if they are generic and you can associate the
dependency to a struct device.

>> Fundamentally, it is a question of probe devices when their
>> dependencies are present or drivers ensure their dependencies are
>> ready. IIRC, init systems went thru a similar debate for service
>> dependencies.
>
> The probe ordering is not the entire picture, though.
>
> Even if you get the probe ordering right, the problem is going to show up in
> multiple other places: system suspend/resume, runtime PM, system shutdown,
> unbinding of drivers.  In all of those cases it is necessary to handle things
> in a specific order if there is a dependency.

My understanding was with deferred probe that it also solves suspend
ordering problems because things are suspended in reverse order of
probing. I suppose you could have slightly different dependencies for
suspend, runtime PM, etc. than for probe? Perhaps we need to save the
list of dependencies as we probe them. I don't think that would be too
hard to add on to this series, but then if we don't need it now, why
add it?

>> >> In any case, we're talking about adding 1 line.
>> >
>> > But also about making the driver core slighly OF-centric.
>>
>> How so? The one line is in DT binding parsing code in subsystems, not
>> driver core. The driver core change is we add every device (that
>> happened to be created by DT) to the deferred probe list, so they
>> don't probe right away.
>
> The "that happened to be created by DT" part is of concern here.  What is there
> that makes DT special in that respect?  Why shouldn't that be applicable to
> devices created by the ACPI core, for example, or by a board file or something
> else?

DT is first. I think both examples could use this. Board files avoid
the problem by controlling the registration order with initcall levels
and just the call order in the code. You could come up with some way
to define dependencies for devices in board files and reuse this
mechanism. ACPI could use this as well if the dependencies are handled
in a similar way and it seems like they could be.

>> > Sure, we need OF-specific code and ACPI-specific code wherever different
>> > handling is required, but doing that at the driver core level seems to be
>> > a bit of a stretch to me.
>> >
>> > Please note that we don't really have ACPI-specific calls in the driver core,
>> > although we might have added them long ago even before the OF stuff appeared
>> > in the kernel for the first time.  We didn't do that, (among other things)
>> > because we didn't want that particular firmware interface to appear special
>> > in any way and I'm not really sure why it is now OK to make OF look special
>> > instead.
>>
>> I don't think DT is special and we avoid DT specific core changes as
>> much as possible. I think the difference is DT uses platform_device
>> and ACPI does not.
>
> ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
> platform devices by default now.

Okay, I should have grepped for that:
drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev, NULL);
drivers/base/platform.c:        len = acpi_device_modalias(dev, buf,
PAGE_SIZE -1);
drivers/base/platform.c:        rc = acpi_device_uevent_modalias(dev, env);
drivers/base/platform.c:        /* Then try ACPI style match */
drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv))

These are all cases which have DT version as well, so we're not really
all that different here. There's a few more for DT, but that probably
means you have just not hit the problems we have yet. For example,
what happens if you have an interrupt line in which the controller is
probed after the device connected to the interrupt line? That required
resolving irqs in platform_get_irq rather than using static resources
to support deferred probe.

Converting things like this to fwnode calls isn't hard to do. There
just hasn't been a pressing need or mandate to do so.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
>> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
>> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> >> >> > But the point I'm making is that we are working towards *fixing* that,
>> >> >> > and *not* using DT-specific code in places where we should be using the
>> >> >> > generic APIs.
>> >> >>
>> >> >> What is the plan for fixing things here?  It's not obvious (at least to
>> >> >> me) that we don't want to have the subsystems having knowledge of how
>> >> >> they are bound to a specific firmware which is what you seem to imply
>> >> >> here.
>> >> >
>> >> > I don't know that there *is* a coherent plan here to address it all.
>> >> >
>> >> > Certainly, we *will* need subsystems to have firmware-specific
>> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
>> >> > describe GPIO, and properties which reference GPIO pins are intended to
>> >> > work through that — while in DT, properties which reference GPIO pins
>> >> > will have different contents. They'll be compatible at the driver
>> >> > level, in the sense that there's a call to get a given GPIO given the
>> >> > property name, but the subsystems *will* be doing different things
>> >> > behind the scenes.
>> >> >
>> >> > My plan, such as it is, is to go through the leaf-node drivers which
>> >> > almost definitely *should* be firmware-agnostic, and convert those. And
>> >> > then take stock of what we have left, and work out what, if anything,
>> >> > still needs to be done.
>> >>
>> >> Many cases are already agnostic in the drivers in terms of the *_get()
>> >> functions. Some are DT specific, but probably because those subsystems
>> >> are new and DT only. In any case, I don't think these 1 line changes
>> >> do anything to make doing conversions here harder.
>> >>
>> >> >> It seems like we're going to have to refactor these bits of code when
>> >> >> they get generalised anyway so I'm not sure that the additional cost
>> >> >> here is that big.
>> >> >
>> >> > That's an acceptable answer — "we're adding legacy code here but we
>> >> > know it's going to be refactored anyway". If that's true, all it takes
>> >> > is a note in the commit comment to that effect. That's different from
>> >> > having not thought about it :)
>> >>
>> >> Considering at one point we did create a fwnode based API, we did
>> >> think about it. Plus there was little input from ACPI folks as to
>> >> whether the change was even useful for ACPI case.
>> >
>> > Well, sorry, but who was asking whom, specifically?
>>
>> You and linux-acpi have been copied on v2 and later of the entire
>> series I think.
>
> Yes, but it wasn't like a direct request, say "We need your input, so can you
> please have a look and BTW we want this in 4.4, so please do it ASAP".  In
> which case I'd prioritize that before other things I needed to take care of.

Fair enough. Can you please review and comment on v7 of the series? We
can discuss at KS as well.

>> > The underlying problem is present in ACPI too and we don't really have a good
>> > solution for it.  We might benefit from a common one if it existed.
>>
>> The problem for DT is we don't generically know what are the
>> dependencies at a core level. We could know some or most dependencies
>> if phandles (links to other nodes) were typed, but they are not. If
>> the core had this information, we could simply control the device
>> creation to order probing. Instead, this information is encoded into
>> the bindings and binding parsing resides in the subsystems. That
>> parsing happens during probe of the client side and is done by the
>> subsystems (for common bindings). Since we already do the parsing at
>> this point, it is a convenient place to trigger the probe of the
>> dependency. Is ACPI going to be similar in this regard?
>
> It is similar in some ways.  For example, if a device's functionality depends
> on an I2C resource (connection), the core doesn't know that at the device
> creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.

So you will need to create devices, defer their probing and then probe
on demand as well unless you have other ideas how you would do it.

> There is a _DEP object in ACPI that can be used by firmware to tell the OS
> about those dependencies, but there's no way in the driver core to use that
> information anyway today.

I would think that the equivalent function for ACPI to of_device_probe
could process these if they are generic and you can associate the
dependency to a struct device.

>> Fundamentally, it is a question of probe devices when their
>> dependencies are present or drivers ensure their dependencies are
>> ready. IIRC, init systems went thru a similar debate for service
>> dependencies.
>
> The probe ordering is not the entire picture, though.
>
> Even if you get the probe ordering right, the problem is going to show up in
> multiple other places: system suspend/resume, runtime PM, system shutdown,
> unbinding of drivers.  In all of those cases it is necessary to handle things
> in a specific order if there is a dependency.

My understanding was with deferred probe that it also solves suspend
ordering problems because things are suspended in reverse order of
probing. I suppose you could have slightly different dependencies for
suspend, runtime PM, etc. than for probe? Perhaps we need to save the
list of dependencies as we probe them. I don't think that would be too
hard to add on to this series, but then if we don't need it now, why
add it?

>> >> In any case, we're talking about adding 1 line.
>> >
>> > But also about making the driver core slighly OF-centric.
>>
>> How so? The one line is in DT binding parsing code in subsystems, not
>> driver core. The driver core change is we add every device (that
>> happened to be created by DT) to the deferred probe list, so they
>> don't probe right away.
>
> The "that happened to be created by DT" part is of concern here.  What is there
> that makes DT special in that respect?  Why shouldn't that be applicable to
> devices created by the ACPI core, for example, or by a board file or something
> else?

DT is first. I think both examples could use this. Board files avoid
the problem by controlling the registration order with initcall levels
and just the call order in the code. You could come up with some way
to define dependencies for devices in board files and reuse this
mechanism. ACPI could use this as well if the dependencies are handled
in a similar way and it seems like they could be.

>> > Sure, we need OF-specific code and ACPI-specific code wherever different
>> > handling is required, but doing that at the driver core level seems to be
>> > a bit of a stretch to me.
>> >
>> > Please note that we don't really have ACPI-specific calls in the driver core,
>> > although we might have added them long ago even before the OF stuff appeared
>> > in the kernel for the first time.  We didn't do that, (among other things)
>> > because we didn't want that particular firmware interface to appear special
>> > in any way and I'm not really sure why it is now OK to make OF look special
>> > instead.
>>
>> I don't think DT is special and we avoid DT specific core changes as
>> much as possible. I think the difference is DT uses platform_device
>> and ACPI does not.
>
> ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
> platform devices by default now.

Okay, I should have grepped for that:
drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev, NULL);
drivers/base/platform.c:        len = acpi_device_modalias(dev, buf,
PAGE_SIZE -1);
drivers/base/platform.c:        rc = acpi_device_uevent_modalias(dev, env);
drivers/base/platform.c:        /* Then try ACPI style match */
drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv))

These are all cases which have DT version as well, so we're not really
all that different here. There's a few more for DT, but that probably
means you have just not hit the problems we have yet. For example,
what happens if you have an interrupt line in which the controller is
probed after the device connected to the interrupt line? That required
resolving irqs in platform_get_irq rather than using static resources
to support deferred probe.

Converting things like this to fwnode calls isn't hard to do. There
just hasn't been a pressing need or mandate to do so.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrot=
e:
> On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
>> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> w=
rote:
>> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
>> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.or=
g> wrote:
>> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> >> >> > But the point I'm making is that we are working towards *fixing*=
 that,
>> >> >> > and *not* using DT-specific code in places where we should be us=
ing the
>> >> >> > generic APIs.
>> >> >>
>> >> >> What is the plan for fixing things here?  It's not obvious (at lea=
st to
>> >> >> me) that we don't want to have the subsystems having knowledge of =
how
>> >> >> they are bound to a specific firmware which is what you seem to im=
ply
>> >> >> here.
>> >> >
>> >> > I don't know that there *is* a coherent plan here to address it all=
.
>> >> >
>> >> > Certainly, we *will* need subsystems to have firmware-specific
>> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way =
to
>> >> > describe GPIO, and properties which reference GPIO pins are intende=
d to
>> >> > work through that =E2=80=94 while in DT, properties which reference=
 GPIO pins
>> >> > will have different contents. They'll be compatible at the driver
>> >> > level, in the sense that there's a call to get a given GPIO given t=
he
>> >> > property name, but the subsystems *will* be doing different things
>> >> > behind the scenes.
>> >> >
>> >> > My plan, such as it is, is to go through the leaf-node drivers whic=
h
>> >> > almost definitely *should* be firmware-agnostic, and convert those.=
 And
>> >> > then take stock of what we have left, and work out what, if anythin=
g,
>> >> > still needs to be done.
>> >>
>> >> Many cases are already agnostic in the drivers in terms of the *_get(=
)
>> >> functions. Some are DT specific, but probably because those subsystem=
s
>> >> are new and DT only. In any case, I don't think these 1 line changes
>> >> do anything to make doing conversions here harder.
>> >>
>> >> >> It seems like we're going to have to refactor these bits of code w=
hen
>> >> >> they get generalised anyway so I'm not sure that the additional co=
st
>> >> >> here is that big.
>> >> >
>> >> > That's an acceptable answer =E2=80=94 "we're adding legacy code her=
e but we
>> >> > know it's going to be refactored anyway". If that's true, all it ta=
kes
>> >> > is a note in the commit comment to that effect. That's different fr=
om
>> >> > having not thought about it :)
>> >>
>> >> Considering at one point we did create a fwnode based API, we did
>> >> think about it. Plus there was little input from ACPI folks as to
>> >> whether the change was even useful for ACPI case.
>> >
>> > Well, sorry, but who was asking whom, specifically?
>>
>> You and linux-acpi have been copied on v2 and later of the entire
>> series I think.
>
> Yes, but it wasn't like a direct request, say "We need your input, so can=
 you
> please have a look and BTW we want this in 4.4, so please do it ASAP".  I=
n
> which case I'd prioritize that before other things I needed to take care =
of.

Fair enough. Can you please review and comment on v7 of the series? We
can discuss at KS as well.

>> > The underlying problem is present in ACPI too and we don't really have=
 a good
>> > solution for it.  We might benefit from a common one if it existed.
>>
>> The problem for DT is we don't generically know what are the
>> dependencies at a core level. We could know some or most dependencies
>> if phandles (links to other nodes) were typed, but they are not. If
>> the core had this information, we could simply control the device
>> creation to order probing. Instead, this information is encoded into
>> the bindings and binding parsing resides in the subsystems. That
>> parsing happens during probe of the client side and is done by the
>> subsystems (for common bindings). Since we already do the parsing at
>> this point, it is a convenient place to trigger the probe of the
>> dependency. Is ACPI going to be similar in this regard?
>
> It is similar in some ways.  For example, if a device's functionality dep=
ends
> on an I2C resource (connection), the core doesn't know that at the device
> creation time at least in some cases.  Same for GPIO, SPI, DMA engines et=
c.

So you will need to create devices, defer their probing and then probe
on demand as well unless you have other ideas how you would do it.

> There is a _DEP object in ACPI that can be used by firmware to tell the O=
S
> about those dependencies, but there's no way in the driver core to use th=
at
> information anyway today.

I would think that the equivalent function for ACPI to of_device_probe
could process these if they are generic and you can associate the
dependency to a struct device.

>> Fundamentally, it is a question of probe devices when their
>> dependencies are present or drivers ensure their dependencies are
>> ready. IIRC, init systems went thru a similar debate for service
>> dependencies.
>
> The probe ordering is not the entire picture, though.
>
> Even if you get the probe ordering right, the problem is going to show up=
 in
> multiple other places: system suspend/resume, runtime PM, system shutdown=
,
> unbinding of drivers.  In all of those cases it is necessary to handle th=
ings
> in a specific order if there is a dependency.

My understanding was with deferred probe that it also solves suspend
ordering problems because things are suspended in reverse order of
probing. I suppose you could have slightly different dependencies for
suspend, runtime PM, etc. than for probe? Perhaps we need to save the
list of dependencies as we probe them. I don't think that would be too
hard to add on to this series, but then if we don't need it now, why
add it?

>> >> In any case, we're talking about adding 1 line.
>> >
>> > But also about making the driver core slighly OF-centric.
>>
>> How so? The one line is in DT binding parsing code in subsystems, not
>> driver core. The driver core change is we add every device (that
>> happened to be created by DT) to the deferred probe list, so they
>> don't probe right away.
>
> The "that happened to be created by DT" part is of concern here.  What is=
 there
> that makes DT special in that respect?  Why shouldn't that be applicable =
to
> devices created by the ACPI core, for example, or by a board file or some=
thing
> else?

DT is first. I think both examples could use this. Board files avoid
the problem by controlling the registration order with initcall levels
and just the call order in the code. You could come up with some way
to define dependencies for devices in board files and reuse this
mechanism. ACPI could use this as well if the dependencies are handled
in a similar way and it seems like they could be.

>> > Sure, we need OF-specific code and ACPI-specific code wherever differe=
nt
>> > handling is required, but doing that at the driver core level seems to=
 be
>> > a bit of a stretch to me.
>> >
>> > Please note that we don't really have ACPI-specific calls in the drive=
r core,
>> > although we might have added them long ago even before the OF stuff ap=
peared
>> > in the kernel for the first time.  We didn't do that, (among other thi=
ngs)
>> > because we didn't want that particular firmware interface to appear sp=
ecial
>> > in any way and I'm not really sure why it is now OK to make OF look sp=
ecial
>> > instead.
>>
>> I don't think DT is special and we avoid DT specific core changes as
>> much as possible. I think the difference is DT uses platform_device
>> and ACPI does not.
>
> ACPI uses platform devices too.  In fact, ACPI device objects are enumera=
ted as
> platform devices by default now.

Okay, I should have grepped for that:
drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev, NULL=
);
drivers/base/platform.c:        len =3D acpi_device_modalias(dev, buf,
PAGE_SIZE -1);
drivers/base/platform.c:        rc =3D acpi_device_uevent_modalias(dev, env=
);
drivers/base/platform.c:        /* Then try ACPI style match */
drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv))

These are all cases which have DT version as well, so we're not really
all that different here. There's a few more for DT, but that probably
means you have just not hit the problems we have yet. For example,
what happens if you have an interrupt line in which the controller is
probed after the device connected to the interrupt line? That required
resolving irqs in platform_get_irq rather than using static resources
to support deferred probe.

Converting things like this to fwnode calls isn't hard to do. There
just hasn't been a pressing need or mandate to do so.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
>> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
>> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
>> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> >> >> > But the point I'm making is that we are working towards *fixing* that,
>> >> >> > and *not* using DT-specific code in places where we should be using the
>> >> >> > generic APIs.
>> >> >>
>> >> >> What is the plan for fixing things here?  It's not obvious (at least to
>> >> >> me) that we don't want to have the subsystems having knowledge of how
>> >> >> they are bound to a specific firmware which is what you seem to imply
>> >> >> here.
>> >> >
>> >> > I don't know that there *is* a coherent plan here to address it all.
>> >> >
>> >> > Certainly, we *will* need subsystems to have firmware-specific
>> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
>> >> > describe GPIO, and properties which reference GPIO pins are intended to
>> >> > work through that — while in DT, properties which reference GPIO pins
>> >> > will have different contents. They'll be compatible at the driver
>> >> > level, in the sense that there's a call to get a given GPIO given the
>> >> > property name, but the subsystems *will* be doing different things
>> >> > behind the scenes.
>> >> >
>> >> > My plan, such as it is, is to go through the leaf-node drivers which
>> >> > almost definitely *should* be firmware-agnostic, and convert those. And
>> >> > then take stock of what we have left, and work out what, if anything,
>> >> > still needs to be done.
>> >>
>> >> Many cases are already agnostic in the drivers in terms of the *_get()
>> >> functions. Some are DT specific, but probably because those subsystems
>> >> are new and DT only. In any case, I don't think these 1 line changes
>> >> do anything to make doing conversions here harder.
>> >>
>> >> >> It seems like we're going to have to refactor these bits of code when
>> >> >> they get generalised anyway so I'm not sure that the additional cost
>> >> >> here is that big.
>> >> >
>> >> > That's an acceptable answer — "we're adding legacy code here but we
>> >> > know it's going to be refactored anyway". If that's true, all it takes
>> >> > is a note in the commit comment to that effect. That's different from
>> >> > having not thought about it :)
>> >>
>> >> Considering at one point we did create a fwnode based API, we did
>> >> think about it. Plus there was little input from ACPI folks as to
>> >> whether the change was even useful for ACPI case.
>> >
>> > Well, sorry, but who was asking whom, specifically?
>>
>> You and linux-acpi have been copied on v2 and later of the entire
>> series I think.
>
> Yes, but it wasn't like a direct request, say "We need your input, so can you
> please have a look and BTW we want this in 4.4, so please do it ASAP".  In
> which case I'd prioritize that before other things I needed to take care of.

Fair enough. Can you please review and comment on v7 of the series? We
can discuss at KS as well.

>> > The underlying problem is present in ACPI too and we don't really have a good
>> > solution for it.  We might benefit from a common one if it existed.
>>
>> The problem for DT is we don't generically know what are the
>> dependencies at a core level. We could know some or most dependencies
>> if phandles (links to other nodes) were typed, but they are not. If
>> the core had this information, we could simply control the device
>> creation to order probing. Instead, this information is encoded into
>> the bindings and binding parsing resides in the subsystems. That
>> parsing happens during probe of the client side and is done by the
>> subsystems (for common bindings). Since we already do the parsing at
>> this point, it is a convenient place to trigger the probe of the
>> dependency. Is ACPI going to be similar in this regard?
>
> It is similar in some ways.  For example, if a device's functionality depends
> on an I2C resource (connection), the core doesn't know that at the device
> creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.

So you will need to create devices, defer their probing and then probe
on demand as well unless you have other ideas how you would do it.

> There is a _DEP object in ACPI that can be used by firmware to tell the OS
> about those dependencies, but there's no way in the driver core to use that
> information anyway today.

I would think that the equivalent function for ACPI to of_device_probe
could process these if they are generic and you can associate the
dependency to a struct device.

>> Fundamentally, it is a question of probe devices when their
>> dependencies are present or drivers ensure their dependencies are
>> ready. IIRC, init systems went thru a similar debate for service
>> dependencies.
>
> The probe ordering is not the entire picture, though.
>
> Even if you get the probe ordering right, the problem is going to show up in
> multiple other places: system suspend/resume, runtime PM, system shutdown,
> unbinding of drivers.  In all of those cases it is necessary to handle things
> in a specific order if there is a dependency.

My understanding was with deferred probe that it also solves suspend
ordering problems because things are suspended in reverse order of
probing. I suppose you could have slightly different dependencies for
suspend, runtime PM, etc. than for probe? Perhaps we need to save the
list of dependencies as we probe them. I don't think that would be too
hard to add on to this series, but then if we don't need it now, why
add it?

>> >> In any case, we're talking about adding 1 line.
>> >
>> > But also about making the driver core slighly OF-centric.
>>
>> How so? The one line is in DT binding parsing code in subsystems, not
>> driver core. The driver core change is we add every device (that
>> happened to be created by DT) to the deferred probe list, so they
>> don't probe right away.
>
> The "that happened to be created by DT" part is of concern here.  What is there
> that makes DT special in that respect?  Why shouldn't that be applicable to
> devices created by the ACPI core, for example, or by a board file or something
> else?

DT is first. I think both examples could use this. Board files avoid
the problem by controlling the registration order with initcall levels
and just the call order in the code. You could come up with some way
to define dependencies for devices in board files and reuse this
mechanism. ACPI could use this as well if the dependencies are handled
in a similar way and it seems like they could be.

>> > Sure, we need OF-specific code and ACPI-specific code wherever different
>> > handling is required, but doing that at the driver core level seems to be
>> > a bit of a stretch to me.
>> >
>> > Please note that we don't really have ACPI-specific calls in the driver core,
>> > although we might have added them long ago even before the OF stuff appeared
>> > in the kernel for the first time.  We didn't do that, (among other things)
>> > because we didn't want that particular firmware interface to appear special
>> > in any way and I'm not really sure why it is now OK to make OF look special
>> > instead.
>>
>> I don't think DT is special and we avoid DT specific core changes as
>> much as possible. I think the difference is DT uses platform_device
>> and ACPI does not.
>
> ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
> platform devices by default now.

Okay, I should have grepped for that:
drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev, NULL);
drivers/base/platform.c:        len = acpi_device_modalias(dev, buf,
PAGE_SIZE -1);
drivers/base/platform.c:        rc = acpi_device_uevent_modalias(dev, env);
drivers/base/platform.c:        /* Then try ACPI style match */
drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv))

These are all cases which have DT version as well, so we're not really
all that different here. There's a few more for DT, but that probably
means you have just not hit the problems we have yet. For example,
what happens if you have an interrupt line in which the controller is
probed after the device connected to the interrupt line? That required
resolving irqs in platform_get_irq rather than using static resources
to support deferred probe.

Converting things like this to fwnode calls isn't hard to do. There
just hasn't been a pressing need or mandate to do so.

Rob

Re: [GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Rob Herring wrote:

> > The probe ordering is not the entire picture, though.
> >
> > Even if you get the probe ordering right, the problem is going to show up in
> > multiple other places: system suspend/resume, runtime PM, system shutdown,
> > unbinding of drivers.  In all of those cases it is necessary to handle things
> > in a specific order if there is a dependency.
> 
> My understanding was with deferred probe that it also solves suspend
> ordering problems because things are suspended in reverse order of
> probing.

Devices are suspended in reverse order of _registration_.  Not of 
probing.

Furthermore, that applies only to devices that use synchronous suspend.  
Async suspend is becoming common, and there the only restrictions are 
parent-child relations plus whatever explicit requirements that drivers 
impose by calling device_pm_wait_for_dev().

Alan Stern

Re: [GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Rob Herring wrote:

> > The probe ordering is not the entire picture, though.
> >
> > Even if you get the probe ordering right, the problem is going to show up in
> > multiple other places: system suspend/resume, runtime PM, system shutdown,
> > unbinding of drivers.  In all of those cases it is necessary to handle things
> > in a specific order if there is a dependency.
> 
> My understanding was with deferred probe that it also solves suspend
> ordering problems because things are suspended in reverse order of
> probing.

Devices are suspended in reverse order of _registration_.  Not of 
probing.

Furthermore, that applies only to devices that use synchronous suspend.  
Async suspend is becoming common, and there the only restrictions are 
parent-child relations plus whatever explicit requirements that drivers 
impose by calling device_pm_wait_for_dev().

Alan Stern

Re: [GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Rob Herring wrote:

> > The probe ordering is not the entire picture, though.
> >
> > Even if you get the probe ordering right, the problem is going to show up in
> > multiple other places: system suspend/resume, runtime PM, system shutdown,
> > unbinding of drivers.  In all of those cases it is necessary to handle things
> > in a specific order if there is a dependency.
> 
> My understanding was with deferred probe that it also solves suspend
> ordering problems because things are suspended in reverse order of
> probing.

Devices are suspended in reverse order of _registration_.  Not of 
probing.

Furthermore, that applies only to devices that use synchronous suspend.  
Async suspend is becoming common, and there the only restrictions are 
parent-child relations plus whatever explicit requirements that drivers 
impose by calling device_pm_wait_for_dev().

Alan Stern

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:

> Furthermore, that applies only to devices that use synchronous suspend.  
> Async suspend is becoming common, and there the only restrictions are 
> parent-child relations plus whatever explicit requirements that drivers 
> impose by calling device_pm_wait_for_dev().

Hrm, this is the first I'd noticed that feature though I see the initial
commit dates from January.  It looks like most of the users are PCs at
the minute but we should be using it more widely for embedded things,
there's definitely some cases I'm aware of where it will allow us to
remove some open coding.

It does seem like we want to be feeding dependency information we
discover for probing way into the suspend dependencies...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:

> Furthermore, that applies only to devices that use synchronous suspend.  
> Async suspend is becoming common, and there the only restrictions are 
> parent-child relations plus whatever explicit requirements that drivers 
> impose by calling device_pm_wait_for_dev().

Hrm, this is the first I'd noticed that feature though I see the initial
commit dates from January.  It looks like most of the users are PCs at
the minute but we should be using it more widely for embedded things,
there's definitely some cases I'm aware of where it will allow us to
remove some open coding.

It does seem like we want to be feeding dependency information we
discover for probing way into the suspend dependencies...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:

> Furthermore, that applies only to devices that use synchronous suspend.  
> Async suspend is becoming common, and there the only restrictions are 
> parent-child relations plus whatever explicit requirements that drivers 
> impose by calling device_pm_wait_for_dev().

Hrm, this is the first I'd noticed that feature though I see the initial
commit dates from January.  It looks like most of the users are PCs at
the minute but we should be using it more widely for embedded things,
there's definitely some cases I'm aware of where it will allow us to
remove some open coding.

It does seem like we want to be feeding dependency information we
discover for probing way into the suspend dependencies...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - possibly augmenting that with reports from
> >> > subsystems showing what resources are not available, but that's only
> >> > a guide, because of the "it might or might not be in a kernel module"
> >> > problem.
> >>
> >> Well, adding those reports would give you a changelog similar to the
> >> one in this series...
> >
> > I'm not sure about that, because what I was thinking of is adding
> > a flag which would be set at late_initcall() time prior to running
> > a final round of deferred device probing.
> 
> Which round is the final round?
> That's the one which didn't manage to bind any new devices to drivers,
> which is something you only know _after_ the round has been run.
> 
> So I think we need one extra round to handle this.
> 
> > This flag would then be used in a deferred_warn() printk function
> > which would normally be silent, but when this flag is set, it would
> > print the reason for the deferral - and this would replace (or be
> > added) to the subsystems and drivers which return -EPROBE_DEFER.
> >
> > That has the effect of hiding all the deferrals up until just before
> > launching into userspace, which should then acomplish two things -
> > firstly, getting rid of the rather useless deferred messages up to
> > that point, and secondly printing the reason why the remaining
> > deferrals are happening.
> >
> > That should be a small number of new lines plus a one-line change
> > in subsystems and drivers.
> 
> Apart from the extra round we probably can't get rid of, that sounds OK to me.

Something like this.  I haven't put a lot of effort into it to change all
the places which return an -EPROBE_DEFER, and it also looks like we need
some helpers to report when we have only an device_node (or should that
be fwnode?)  See the commented out of_warn_deferred() in
drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
for resources should make debugging why things are getting deferred easier.

We could make driver_deferred_probe_report something that can be
deactivated again after the last deferred probe run, and provide the
user with a knob that they can turn it back on again.

I've tried this out on two of my platforms, including forcing
driver_deferred_probe_report to be enabled, and I get exactly one
deferred probe, so not a particularly good test.

The patch won't apply as-is to mainline for all files; it's based on my
tree which has some 360 additional patches (which seems to be about
normal for my tree now.)

 drivers/base/dd.c                       | 29 +++++++++++++++++++++++++++++
 drivers/base/power/domain.c             |  7 +++++--
 drivers/clk/clkdev.c                    |  9 ++++++++-
 drivers/gpio/gpiolib-of.c               |  5 +++++
 drivers/gpu/drm/bridge/dw_hdmi.c        |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
 drivers/gpu/drm/imx/imx-ldb.c           |  5 +++--
 drivers/gpu/drm/msm/dsi/dsi.c           |  2 +-
 drivers/gpu/drm/msm/msm_drv.c           |  3 ++-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
 drivers/of/irq.c                        |  5 ++++-
 drivers/pci/host/pci-mvebu.c            |  1 +
 drivers/pinctrl/core.c                  |  5 +++--
 drivers/pinctrl/devicetree.c            |  4 ++--
 drivers/regulator/core.c                |  5 +++--
 include/linux/device.h                  |  1 +
 16 files changed, 71 insertions(+), 17 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index be0eb4639128..bb12224f2901 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev)
 	mutex_unlock(&deferred_probe_mutex);
 }
 
+static bool driver_deferred_probe_report;
+
+/**
+ * dev_warn_deferred() - report why a probe has been deferred
+ */
+void dev_warn_deferred(struct device *dev, const char *fmt, ...)
+{
+	if (driver_deferred_probe_report) {
+		struct va_format vaf;
+		va_list ap;
+
+		va_start(ap, fmt);
+		vaf.fmt = fmt;
+		vaf.va = &ap;
+
+		dev_warn(dev, "deferring probe: %pV", &vaf);
+		va_end(ap);
+	}
+}
+EXPORT_SYMBOL_GPL(dev_warn_deferred);
+
 static bool driver_deferred_probe_enable = false;
+
 /**
  * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
  *
@@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
 	driver_deferred_probe_trigger();
 	/* Sort as many dependencies as possible before exiting initcalls */
 	flush_workqueue(deferred_wq);
+
+	/* Now one final round, reporting any devices that remain deferred */
+	driver_deferred_probe_report = true;
+	driver_deferred_probe_trigger();
+	/* Sort as many dependencies as possible before exiting initcalls */
+	flush_workqueue(deferred_wq);
+
 	return 0;
 }
 late_initcall(deferred_probe_initcall);
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 16550c63d611..9f4d687d7268 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1997,8 +1997,8 @@ int genpd_dev_pm_attach(struct device *dev)
 
 	pd = of_genpd_get_from_provider(&pd_args);
 	if (IS_ERR(pd)) {
-		dev_dbg(dev, "%s() failed to find PM domain: %ld\n",
-			__func__, PTR_ERR(pd));
+		dev_warn_deferred(dev, "%s() failed to find PM domain: %ld\n",
+				  __func__, PTR_ERR(pd));
 		of_node_put(dev->of_node);
 		return -EPROBE_DEFER;
 	}
@@ -2026,6 +2026,9 @@ int genpd_dev_pm_attach(struct device *dev)
 	ret = pm_genpd_poweron(pd);
 
 out:
+	if (ret)
+		dev_warn_deferred(dev, "%s() deferring probe: %d\n",
+				  __func__, ret);
 	return ret ? -EPROBE_DEFER : 0;
 }
 EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 779b6ff0c7ad..66f4212c63fd 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -201,7 +201,14 @@ struct clk *clk_get(struct device *dev, const char *con_id)
 
 	if (dev) {
 		clk = __of_clk_get_by_name(dev->of_node, dev_id, con_id);
-		if (!IS_ERR(clk) || PTR_ERR(clk) == -EPROBE_DEFER)
+		if (IS_ERR(clk) && PTR_ERR(clk) == -EPROBE_DEFER) {
+			if (dev)
+				dev_warn_deferred(dev,
+						  "unable to locate clock for connection %s\n",
+						  con_id);
+			return clk;
+		}
+		if (!IS_ERR(clk))
 			return clk;
 	}
 
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index fa6e3c8823d6..36f09ab1c215 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -101,6 +101,11 @@ struct gpio_desc *of_get_named_gpiod_flags(struct device_node *np,
 	pr_debug("%s: parsed '%s' property of node '%s[%d]' - status (%d)\n",
 		 __func__, propname, np->full_name, index,
 		 PTR_ERR_OR_ZERO(gg_data.out_gpio));
+
+//	if (gg_data.out_gpio == -EPROBE_DEFER)
+//		of_warn_deferred(np, "%s: unable to locate GPIO for %s[%d]\n",
+//				 __func__, propname, index);
+
 	return gg_data.out_gpio;
 }
 
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index cb8764eecd70..088f5dd58424 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1785,7 +1785,7 @@ int dw_hdmi_bind(struct device *dev, struct device *master,
 		hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
 		of_node_put(ddc_node);
 		if (!hdmi->ddc) {
-			dev_dbg(hdmi->dev, "failed to read ddc node\n");
+			dev_warn_deferred(hdmi->dev, "failed to read ddc node\n");
 			return -EPROBE_DEFER;
 		}
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 12b03b364703..3155798d8245 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1899,7 +1899,7 @@ static int exynos_dsi_probe(struct platform_device *pdev)
 	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
 				      dsi->supplies);
 	if (ret) {
-		dev_info(dev, "failed to get regulators: %d\n", ret);
+		dev_warn_deferred(dev, "failed to get regulators: %d\n", ret);
 		return -EPROBE_DEFER;
 	}
 
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index abacc8f67469..0b57054c886a 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -595,8 +595,9 @@ static int imx_ldb_bind(struct device *dev, struct device *master, void *data)
 				else
 					return -EPROBE_DEFER;
 				if (!channel->panel) {
-					dev_err(dev, "panel not found: %s\n",
-						remote->full_name);
+					dev_warn_deferred(dev,
+							  "panel not found: %s\n",
+							  remote->full_name);
 					return -EPROBE_DEFER;
 				}
 			}
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 6edcd6f57e70..3ba94a2bca65 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -42,7 +42,7 @@ static int dsi_get_phy(struct msm_dsi *msm_dsi)
 	of_node_put(phy_node);
 
 	if (!phy_pdev || !msm_dsi->phy) {
-		dev_err(&pdev->dev, "%s: phy driver is not ready\n", __func__);
+		dev_warn_deferred(&pdev->dev, "%s: phy driver is not ready\n", __func__);
 		return -EPROBE_DEFER;
 	}
 
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 0339c5d82d37..e1cfcd38c0dd 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1117,7 +1117,8 @@ static int msm_pdev_probe(struct platform_device *pdev)
 		dev = bus_find_device_by_name(&platform_bus_type,
 				NULL, devnames[i]);
 		if (!dev) {
-			dev_info(&pdev->dev, "still waiting for %s\n", devnames[i]);
+			dev_warn_deferred(&pdev->dev, "waiting for %s\n",
+					  devnames[i]);
 			return -EPROBE_DEFER;
 		}
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 48cb19949ca3..bbf36f68d4e0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -600,7 +600,8 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, unsigned int index)
 	if (!IS_ERR(clk)) {
 		rcrtc->extclock = clk;
 	} else if (PTR_ERR(rcrtc->clock) == -EPROBE_DEFER) {
-		dev_info(rcdu->dev, "can't get external clock %u\n", index);
+		dev_warn_deferred(rcdu->dev, "can't get external clock %u\n",
+				  index);
 		return -EPROBE_DEFER;
 	}
 
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 55317fa9c9dc..2056bb9e4c43 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -404,8 +404,11 @@ int of_irq_get(struct device_node *dev, int index)
 		return rc;
 
 	domain = irq_find_host(oirq.np);
-	if (!domain)
+	if (!domain) {
+		dev_warn_deferred(dev, "%s() failed to locate IRQ domain\n",
+				  __func__);
 		return -EPROBE_DEFER;
+	}
 
 	return irq_create_of_mapping(&oirq);
 }
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 0e9b82095dc9..b49ae4822a5b 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -1203,6 +1203,7 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
 
 	reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, &flags);
 	if (reset_gpio == -EPROBE_DEFER) {
+		dev_warn_deferred(dev, "unable to find reset gpio\n");
 		ret = reset_gpio;
 		goto err;
 	}
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 9638a00c67c2..299aae3bca14 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -741,8 +741,9 @@ static int add_setting(struct pinctrl *p, struct pinctrl_map const *map)
 		 * OK let us guess that the driver is not there yet, and
 		 * let's defer obtaining this pinctrl handle to later...
 		 */
-		dev_info(p->dev, "unknown pinctrl device %s in map entry, deferring probe",
-			map->ctrl_dev_name);
+		dev_warn_deferred(p->dev,
+				  "unknown pinctrl device %s in map entry, deferring probe",
+				  map->ctrl_dev_name);
 		return -EPROBE_DEFER;
 	}
 
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
index fe04e748dfe4..358f946471c9 100644
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -115,8 +115,8 @@ static int dt_to_map_one_config(struct pinctrl *p, const char *statename,
 	for (;;) {
 		np_pctldev = of_get_next_parent(np_pctldev);
 		if (!np_pctldev || of_node_is_root(np_pctldev)) {
-			dev_info(p->dev, "could not find pctldev for node %s, deferring probe\n",
-				np_config->full_name);
+			dev_warn_deferred(p->dev, "could not find pctldev for node %s, deferring probe\n",
+					  np_config->full_name);
 			of_node_put(np_pctldev);
 			/* OK let's just assume this will appear later then */
 			return -EPROBE_DEFER;
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 8a34f6acc801..8d8ea0518283 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1410,8 +1410,9 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
 		if (have_full_constraints()) {
 			r = dummy_regulator_rdev;
 		} else {
-			dev_err(dev, "Failed to resolve %s-supply for %s\n",
-				rdev->supply_name, rdev->desc->name);
+			dev_warn_deferred(dev,
+					  "Failed to resolve %s-supply for %s\n",
+					  rdev->supply_name, rdev->desc->name);
 			return -EPROBE_DEFER;
 		}
 	}
diff --git a/include/linux/device.h b/include/linux/device.h
index 5d7bc6349930..5050ce7d73b3 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1087,6 +1087,7 @@ extern void device_shutdown(void);
 /* debugging and troubleshooting/diagnostic helpers. */
 extern const char *dev_driver_string(const struct device *dev);
 
+void dev_warn_deferred(struct device *dev, const char *fmt, ...);
 
 #ifdef CONFIG_PRINTK
 


-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - possibly augmenting that with reports from
> >> > subsystems showing what resources are not available, but that's only
> >> > a guide, because of the "it might or might not be in a kernel module"
> >> > problem.
> >>
> >> Well, adding those reports would give you a changelog similar to the
> >> one in this series...
> >
> > I'm not sure about that, because what I was thinking of is adding
> > a flag which would be set at late_initcall() time prior to running
> > a final round of deferred device probing.
> 
> Which round is the final round?
> That's the one which didn't manage to bind any new devices to drivers,
> which is something you only know _after_ the round has been run.
> 
> So I think we need one extra round to handle this.
> 
> > This flag would then be used in a deferred_warn() printk function
> > which would normally be silent, but when this flag is set, it would
> > print the reason for the deferral - and this would replace (or be
> > added) to the subsystems and drivers which return -EPROBE_DEFER.
> >
> > That has the effect of hiding all the deferrals up until just before
> > launching into userspace, which should then acomplish two things -
> > firstly, getting rid of the rather useless deferred messages up to
> > that point, and secondly printing the reason why the remaining
> > deferrals are happening.
> >
> > That should be a small number of new lines plus a one-line change
> > in subsystems and drivers.
> 
> Apart from the extra round we probably can't get rid of, that sounds OK to me.

Something like this.  I haven't put a lot of effort into it to change all
the places which return an -EPROBE_DEFER, and it also looks like we need
some helpers to report when we have only an device_node (or should that
be fwnode?)  See the commented out of_warn_deferred() in
drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
for resources should make debugging why things are getting deferred easier.

We could make driver_deferred_probe_report something that can be
deactivated again after the last deferred probe run, and provide the
user with a knob that they can turn it back on again.

I've tried this out on two of my platforms, including forcing
driver_deferred_probe_report to be enabled, and I get exactly one
deferred probe, so not a particularly good test.

The patch won't apply as-is to mainline for all files; it's based on my
tree which has some 360 additional patches (which seems to be about
normal for my tree now.)

 drivers/base/dd.c                       | 29 +++++++++++++++++++++++++++++
 drivers/base/power/domain.c             |  7 +++++--
 drivers/clk/clkdev.c                    |  9 ++++++++-
 drivers/gpio/gpiolib-of.c               |  5 +++++
 drivers/gpu/drm/bridge/dw_hdmi.c        |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
 drivers/gpu/drm/imx/imx-ldb.c           |  5 +++--
 drivers/gpu/drm/msm/dsi/dsi.c           |  2 +-
 drivers/gpu/drm/msm/msm_drv.c           |  3 ++-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
 drivers/of/irq.c                        |  5 ++++-
 drivers/pci/host/pci-mvebu.c            |  1 +
 drivers/pinctrl/core.c                  |  5 +++--
 drivers/pinctrl/devicetree.c            |  4 ++--
 drivers/regulator/core.c                |  5 +++--
 include/linux/device.h                  |  1 +
 16 files changed, 71 insertions(+), 17 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index be0eb4639128..bb12224f2901 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev)
 	mutex_unlock(&deferred_probe_mutex);
 }
 
+static bool driver_deferred_probe_report;
+
+/**
+ * dev_warn_deferred() - report why a probe has been deferred
+ */
+void dev_warn_deferred(struct device *dev, const char *fmt, ...)
+{
+	if (driver_deferred_probe_report) {
+		struct va_format vaf;
+		va_list ap;
+
+		va_start(ap, fmt);
+		vaf.fmt = fmt;
+		vaf.va = &ap;
+
+		dev_warn(dev, "deferring probe: %pV", &vaf);
+		va_end(ap);
+	}
+}
+EXPORT_SYMBOL_GPL(dev_warn_deferred);
+
 static bool driver_deferred_probe_enable = false;
+
 /**
  * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
  *
@@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
 	driver_deferred_probe_trigger();
 	/* Sort as many dependencies as possible before exiting initcalls */
 	flush_workqueue(deferred_wq);
+
+	/* Now one final round, reporting any devices that remain deferred */
+	driver_deferred_probe_report = true;
+	driver_deferred_probe_trigger();
+	/* Sort as many dependencies as possible before exiting initcalls */
+	flush_workqueue(deferred_wq);
+
 	return 0;
 }
 late_initcall(deferred_probe_initcall);
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 16550c63d611..9f4d687d7268 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1997,8 +1997,8 @@ int genpd_dev_pm_attach(struct device *dev)
 
 	pd = of_genpd_get_from_provider(&pd_args);
 	if (IS_ERR(pd)) {
-		dev_dbg(dev, "%s() failed to find PM domain: %ld\n",
-			__func__, PTR_ERR(pd));
+		dev_warn_deferred(dev, "%s() failed to find PM domain: %ld\n",
+				  __func__, PTR_ERR(pd));
 		of_node_put(dev->of_node);
 		return -EPROBE_DEFER;
 	}
@@ -2026,6 +2026,9 @@ int genpd_dev_pm_attach(struct device *dev)
 	ret = pm_genpd_poweron(pd);
 
 out:
+	if (ret)
+		dev_warn_deferred(dev, "%s() deferring probe: %d\n",
+				  __func__, ret);
 	return ret ? -EPROBE_DEFER : 0;
 }
 EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 779b6ff0c7ad..66f4212c63fd 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -201,7 +201,14 @@ struct clk *clk_get(struct device *dev, const char *con_id)
 
 	if (dev) {
 		clk = __of_clk_get_by_name(dev->of_node, dev_id, con_id);
-		if (!IS_ERR(clk) || PTR_ERR(clk) == -EPROBE_DEFER)
+		if (IS_ERR(clk) && PTR_ERR(clk) == -EPROBE_DEFER) {
+			if (dev)
+				dev_warn_deferred(dev,
+						  "unable to locate clock for connection %s\n",
+						  con_id);
+			return clk;
+		}
+		if (!IS_ERR(clk))
 			return clk;
 	}
 
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index fa6e3c8823d6..36f09ab1c215 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -101,6 +101,11 @@ struct gpio_desc *of_get_named_gpiod_flags(struct device_node *np,
 	pr_debug("%s: parsed '%s' property of node '%s[%d]' - status (%d)\n",
 		 __func__, propname, np->full_name, index,
 		 PTR_ERR_OR_ZERO(gg_data.out_gpio));
+
+//	if (gg_data.out_gpio == -EPROBE_DEFER)
+//		of_warn_deferred(np, "%s: unable to locate GPIO for %s[%d]\n",
+//				 __func__, propname, index);
+
 	return gg_data.out_gpio;
 }
 
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index cb8764eecd70..088f5dd58424 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1785,7 +1785,7 @@ int dw_hdmi_bind(struct device *dev, struct device *master,
 		hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
 		of_node_put(ddc_node);
 		if (!hdmi->ddc) {
-			dev_dbg(hdmi->dev, "failed to read ddc node\n");
+			dev_warn_deferred(hdmi->dev, "failed to read ddc node\n");
 			return -EPROBE_DEFER;
 		}
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 12b03b364703..3155798d8245 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1899,7 +1899,7 @@ static int exynos_dsi_probe(struct platform_device *pdev)
 	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
 				      dsi->supplies);
 	if (ret) {
-		dev_info(dev, "failed to get regulators: %d\n", ret);
+		dev_warn_deferred(dev, "failed to get regulators: %d\n", ret);
 		return -EPROBE_DEFER;
 	}
 
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index abacc8f67469..0b57054c886a 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -595,8 +595,9 @@ static int imx_ldb_bind(struct device *dev, struct device *master, void *data)
 				else
 					return -EPROBE_DEFER;
 				if (!channel->panel) {
-					dev_err(dev, "panel not found: %s\n",
-						remote->full_name);
+					dev_warn_deferred(dev,
+							  "panel not found: %s\n",
+							  remote->full_name);
 					return -EPROBE_DEFER;
 				}
 			}
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 6edcd6f57e70..3ba94a2bca65 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -42,7 +42,7 @@ static int dsi_get_phy(struct msm_dsi *msm_dsi)
 	of_node_put(phy_node);
 
 	if (!phy_pdev || !msm_dsi->phy) {
-		dev_err(&pdev->dev, "%s: phy driver is not ready\n", __func__);
+		dev_warn_deferred(&pdev->dev, "%s: phy driver is not ready\n", __func__);
 		return -EPROBE_DEFER;
 	}
 
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 0339c5d82d37..e1cfcd38c0dd 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1117,7 +1117,8 @@ static int msm_pdev_probe(struct platform_device *pdev)
 		dev = bus_find_device_by_name(&platform_bus_type,
 				NULL, devnames[i]);
 		if (!dev) {
-			dev_info(&pdev->dev, "still waiting for %s\n", devnames[i]);
+			dev_warn_deferred(&pdev->dev, "waiting for %s\n",
+					  devnames[i]);
 			return -EPROBE_DEFER;
 		}
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 48cb19949ca3..bbf36f68d4e0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -600,7 +600,8 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, unsigned int index)
 	if (!IS_ERR(clk)) {
 		rcrtc->extclock = clk;
 	} else if (PTR_ERR(rcrtc->clock) == -EPROBE_DEFER) {
-		dev_info(rcdu->dev, "can't get external clock %u\n", index);
+		dev_warn_deferred(rcdu->dev, "can't get external clock %u\n",
+				  index);
 		return -EPROBE_DEFER;
 	}
 
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 55317fa9c9dc..2056bb9e4c43 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -404,8 +404,11 @@ int of_irq_get(struct device_node *dev, int index)
 		return rc;
 
 	domain = irq_find_host(oirq.np);
-	if (!domain)
+	if (!domain) {
+		dev_warn_deferred(dev, "%s() failed to locate IRQ domain\n",
+				  __func__);
 		return -EPROBE_DEFER;
+	}
 
 	return irq_create_of_mapping(&oirq);
 }
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 0e9b82095dc9..b49ae4822a5b 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -1203,6 +1203,7 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
 
 	reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, &flags);
 	if (reset_gpio == -EPROBE_DEFER) {
+		dev_warn_deferred(dev, "unable to find reset gpio\n");
 		ret = reset_gpio;
 		goto err;
 	}
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 9638a00c67c2..299aae3bca14 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -741,8 +741,9 @@ static int add_setting(struct pinctrl *p, struct pinctrl_map const *map)
 		 * OK let us guess that the driver is not there yet, and
 		 * let's defer obtaining this pinctrl handle to later...
 		 */
-		dev_info(p->dev, "unknown pinctrl device %s in map entry, deferring probe",
-			map->ctrl_dev_name);
+		dev_warn_deferred(p->dev,
+				  "unknown pinctrl device %s in map entry, deferring probe",
+				  map->ctrl_dev_name);
 		return -EPROBE_DEFER;
 	}
 
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
index fe04e748dfe4..358f946471c9 100644
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -115,8 +115,8 @@ static int dt_to_map_one_config(struct pinctrl *p, const char *statename,
 	for (;;) {
 		np_pctldev = of_get_next_parent(np_pctldev);
 		if (!np_pctldev || of_node_is_root(np_pctldev)) {
-			dev_info(p->dev, "could not find pctldev for node %s, deferring probe\n",
-				np_config->full_name);
+			dev_warn_deferred(p->dev, "could not find pctldev for node %s, deferring probe\n",
+					  np_config->full_name);
 			of_node_put(np_pctldev);
 			/* OK let's just assume this will appear later then */
 			return -EPROBE_DEFER;
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 8a34f6acc801..8d8ea0518283 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1410,8 +1410,9 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
 		if (have_full_constraints()) {
 			r = dummy_regulator_rdev;
 		} else {
-			dev_err(dev, "Failed to resolve %s-supply for %s\n",
-				rdev->supply_name, rdev->desc->name);
+			dev_warn_deferred(dev,
+					  "Failed to resolve %s-supply for %s\n",
+					  rdev->supply_name, rdev->desc->name);
 			return -EPROBE_DEFER;
 		}
 	}
diff --git a/include/linux/device.h b/include/linux/device.h
index 5d7bc6349930..5050ce7d73b3 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1087,6 +1087,7 @@ extern void device_shutdown(void);
 /* debugging and troubleshooting/diagnostic helpers. */
 extern const char *dev_driver_string(const struct device *dev);
 
+void dev_warn_deferred(struct device *dev, const char *fmt, ...);
 
 #ifdef CONFIG_PRINTK
 


-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - possibly augmenting that with reports from
> >> > subsystems showing what resources are not available, but that's only
> >> > a guide, because of the "it might or might not be in a kernel module"
> >> > problem.
> >>
> >> Well, adding those reports would give you a changelog similar to the
> >> one in this series...
> >
> > I'm not sure about that, because what I was thinking of is adding
> > a flag which would be set at late_initcall() time prior to running
> > a final round of deferred device probing.
> 
> Which round is the final round?
> That's the one which didn't manage to bind any new devices to drivers,
> which is something you only know _after_ the round has been run.
> 
> So I think we need one extra round to handle this.
> 
> > This flag would then be used in a deferred_warn() printk function
> > which would normally be silent, but when this flag is set, it would
> > print the reason for the deferral - and this would replace (or be
> > added) to the subsystems and drivers which return -EPROBE_DEFER.
> >
> > That has the effect of hiding all the deferrals up until just before
> > launching into userspace, which should then acomplish two things -
> > firstly, getting rid of the rather useless deferred messages up to
> > that point, and secondly printing the reason why the remaining
> > deferrals are happening.
> >
> > That should be a small number of new lines plus a one-line change
> > in subsystems and drivers.
> 
> Apart from the extra round we probably can't get rid of, that sounds OK to me.

Something like this.  I haven't put a lot of effort into it to change all
the places which return an -EPROBE_DEFER, and it also looks like we need
some helpers to report when we have only an device_node (or should that
be fwnode?)  See the commented out of_warn_deferred() in
drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
for resources should make debugging why things are getting deferred easier.

We could make driver_deferred_probe_report something that can be
deactivated again after the last deferred probe run, and provide the
user with a knob that they can turn it back on again.

I've tried this out on two of my platforms, including forcing
driver_deferred_probe_report to be enabled, and I get exactly one
deferred probe, so not a particularly good test.

The patch won't apply as-is to mainline for all files; it's based on my
tree which has some 360 additional patches (which seems to be about
normal for my tree now.)

 drivers/base/dd.c                       | 29 +++++++++++++++++++++++++++++
 drivers/base/power/domain.c             |  7 +++++--
 drivers/clk/clkdev.c                    |  9 ++++++++-
 drivers/gpio/gpiolib-of.c               |  5 +++++
 drivers/gpu/drm/bridge/dw_hdmi.c        |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
 drivers/gpu/drm/imx/imx-ldb.c           |  5 +++--
 drivers/gpu/drm/msm/dsi/dsi.c           |  2 +-
 drivers/gpu/drm/msm/msm_drv.c           |  3 ++-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
 drivers/of/irq.c                        |  5 ++++-
 drivers/pci/host/pci-mvebu.c            |  1 +
 drivers/pinctrl/core.c                  |  5 +++--
 drivers/pinctrl/devicetree.c            |  4 ++--
 drivers/regulator/core.c                |  5 +++--
 include/linux/device.h                  |  1 +
 16 files changed, 71 insertions(+), 17 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index be0eb4639128..bb12224f2901 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev)
 	mutex_unlock(&deferred_probe_mutex);
 }
 
+static bool driver_deferred_probe_report;
+
+/**
+ * dev_warn_deferred() - report why a probe has been deferred
+ */
+void dev_warn_deferred(struct device *dev, const char *fmt, ...)
+{
+	if (driver_deferred_probe_report) {
+		struct va_format vaf;
+		va_list ap;
+
+		va_start(ap, fmt);
+		vaf.fmt = fmt;
+		vaf.va = &ap;
+
+		dev_warn(dev, "deferring probe: %pV", &vaf);
+		va_end(ap);
+	}
+}
+EXPORT_SYMBOL_GPL(dev_warn_deferred);
+
 static bool driver_deferred_probe_enable = false;
+
 /**
  * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
  *
@@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
 	driver_deferred_probe_trigger();
 	/* Sort as many dependencies as possible before exiting initcalls */
 	flush_workqueue(deferred_wq);
+
+	/* Now one final round, reporting any devices that remain deferred */
+	driver_deferred_probe_report = true;
+	driver_deferred_probe_trigger();
+	/* Sort as many dependencies as possible before exiting initcalls */
+	flush_workqueue(deferred_wq);
+
 	return 0;
 }
 late_initcall(deferred_probe_initcall);
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 16550c63d611..9f4d687d7268 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1997,8 +1997,8 @@ int genpd_dev_pm_attach(struct device *dev)
 
 	pd = of_genpd_get_from_provider(&pd_args);
 	if (IS_ERR(pd)) {
-		dev_dbg(dev, "%s() failed to find PM domain: %ld\n",
-			__func__, PTR_ERR(pd));
+		dev_warn_deferred(dev, "%s() failed to find PM domain: %ld\n",
+				  __func__, PTR_ERR(pd));
 		of_node_put(dev->of_node);
 		return -EPROBE_DEFER;
 	}
@@ -2026,6 +2026,9 @@ int genpd_dev_pm_attach(struct device *dev)
 	ret = pm_genpd_poweron(pd);
 
 out:
+	if (ret)
+		dev_warn_deferred(dev, "%s() deferring probe: %d\n",
+				  __func__, ret);
 	return ret ? -EPROBE_DEFER : 0;
 }
 EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 779b6ff0c7ad..66f4212c63fd 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -201,7 +201,14 @@ struct clk *clk_get(struct device *dev, const char *con_id)
 
 	if (dev) {
 		clk = __of_clk_get_by_name(dev->of_node, dev_id, con_id);
-		if (!IS_ERR(clk) || PTR_ERR(clk) = -EPROBE_DEFER)
+		if (IS_ERR(clk) && PTR_ERR(clk) = -EPROBE_DEFER) {
+			if (dev)
+				dev_warn_deferred(dev,
+						  "unable to locate clock for connection %s\n",
+						  con_id);
+			return clk;
+		}
+		if (!IS_ERR(clk))
 			return clk;
 	}
 
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index fa6e3c8823d6..36f09ab1c215 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -101,6 +101,11 @@ struct gpio_desc *of_get_named_gpiod_flags(struct device_node *np,
 	pr_debug("%s: parsed '%s' property of node '%s[%d]' - status (%d)\n",
 		 __func__, propname, np->full_name, index,
 		 PTR_ERR_OR_ZERO(gg_data.out_gpio));
+
+//	if (gg_data.out_gpio = -EPROBE_DEFER)
+//		of_warn_deferred(np, "%s: unable to locate GPIO for %s[%d]\n",
+//				 __func__, propname, index);
+
 	return gg_data.out_gpio;
 }
 
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index cb8764eecd70..088f5dd58424 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1785,7 +1785,7 @@ int dw_hdmi_bind(struct device *dev, struct device *master,
 		hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
 		of_node_put(ddc_node);
 		if (!hdmi->ddc) {
-			dev_dbg(hdmi->dev, "failed to read ddc node\n");
+			dev_warn_deferred(hdmi->dev, "failed to read ddc node\n");
 			return -EPROBE_DEFER;
 		}
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 12b03b364703..3155798d8245 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1899,7 +1899,7 @@ static int exynos_dsi_probe(struct platform_device *pdev)
 	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(dsi->supplies),
 				      dsi->supplies);
 	if (ret) {
-		dev_info(dev, "failed to get regulators: %d\n", ret);
+		dev_warn_deferred(dev, "failed to get regulators: %d\n", ret);
 		return -EPROBE_DEFER;
 	}
 
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index abacc8f67469..0b57054c886a 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -595,8 +595,9 @@ static int imx_ldb_bind(struct device *dev, struct device *master, void *data)
 				else
 					return -EPROBE_DEFER;
 				if (!channel->panel) {
-					dev_err(dev, "panel not found: %s\n",
-						remote->full_name);
+					dev_warn_deferred(dev,
+							  "panel not found: %s\n",
+							  remote->full_name);
 					return -EPROBE_DEFER;
 				}
 			}
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 6edcd6f57e70..3ba94a2bca65 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -42,7 +42,7 @@ static int dsi_get_phy(struct msm_dsi *msm_dsi)
 	of_node_put(phy_node);
 
 	if (!phy_pdev || !msm_dsi->phy) {
-		dev_err(&pdev->dev, "%s: phy driver is not ready\n", __func__);
+		dev_warn_deferred(&pdev->dev, "%s: phy driver is not ready\n", __func__);
 		return -EPROBE_DEFER;
 	}
 
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 0339c5d82d37..e1cfcd38c0dd 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1117,7 +1117,8 @@ static int msm_pdev_probe(struct platform_device *pdev)
 		dev = bus_find_device_by_name(&platform_bus_type,
 				NULL, devnames[i]);
 		if (!dev) {
-			dev_info(&pdev->dev, "still waiting for %s\n", devnames[i]);
+			dev_warn_deferred(&pdev->dev, "waiting for %s\n",
+					  devnames[i]);
 			return -EPROBE_DEFER;
 		}
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 48cb19949ca3..bbf36f68d4e0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -600,7 +600,8 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, unsigned int index)
 	if (!IS_ERR(clk)) {
 		rcrtc->extclock = clk;
 	} else if (PTR_ERR(rcrtc->clock) = -EPROBE_DEFER) {
-		dev_info(rcdu->dev, "can't get external clock %u\n", index);
+		dev_warn_deferred(rcdu->dev, "can't get external clock %u\n",
+				  index);
 		return -EPROBE_DEFER;
 	}
 
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 55317fa9c9dc..2056bb9e4c43 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -404,8 +404,11 @@ int of_irq_get(struct device_node *dev, int index)
 		return rc;
 
 	domain = irq_find_host(oirq.np);
-	if (!domain)
+	if (!domain) {
+		dev_warn_deferred(dev, "%s() failed to locate IRQ domain\n",
+				  __func__);
 		return -EPROBE_DEFER;
+	}
 
 	return irq_create_of_mapping(&oirq);
 }
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 0e9b82095dc9..b49ae4822a5b 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -1203,6 +1203,7 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
 
 	reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, &flags);
 	if (reset_gpio = -EPROBE_DEFER) {
+		dev_warn_deferred(dev, "unable to find reset gpio\n");
 		ret = reset_gpio;
 		goto err;
 	}
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 9638a00c67c2..299aae3bca14 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -741,8 +741,9 @@ static int add_setting(struct pinctrl *p, struct pinctrl_map const *map)
 		 * OK let us guess that the driver is not there yet, and
 		 * let's defer obtaining this pinctrl handle to later...
 		 */
-		dev_info(p->dev, "unknown pinctrl device %s in map entry, deferring probe",
-			map->ctrl_dev_name);
+		dev_warn_deferred(p->dev,
+				  "unknown pinctrl device %s in map entry, deferring probe",
+				  map->ctrl_dev_name);
 		return -EPROBE_DEFER;
 	}
 
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
index fe04e748dfe4..358f946471c9 100644
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -115,8 +115,8 @@ static int dt_to_map_one_config(struct pinctrl *p, const char *statename,
 	for (;;) {
 		np_pctldev = of_get_next_parent(np_pctldev);
 		if (!np_pctldev || of_node_is_root(np_pctldev)) {
-			dev_info(p->dev, "could not find pctldev for node %s, deferring probe\n",
-				np_config->full_name);
+			dev_warn_deferred(p->dev, "could not find pctldev for node %s, deferring probe\n",
+					  np_config->full_name);
 			of_node_put(np_pctldev);
 			/* OK let's just assume this will appear later then */
 			return -EPROBE_DEFER;
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 8a34f6acc801..8d8ea0518283 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1410,8 +1410,9 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
 		if (have_full_constraints()) {
 			r = dummy_regulator_rdev;
 		} else {
-			dev_err(dev, "Failed to resolve %s-supply for %s\n",
-				rdev->supply_name, rdev->desc->name);
+			dev_warn_deferred(dev,
+					  "Failed to resolve %s-supply for %s\n",
+					  rdev->supply_name, rdev->desc->name);
 			return -EPROBE_DEFER;
 		}
 	}
diff --git a/include/linux/device.h b/include/linux/device.h
index 5d7bc6349930..5050ce7d73b3 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1087,6 +1087,7 @@ extern void device_shutdown(void);
 /* debugging and troubleshooting/diagnostic helpers. */
 extern const char *dev_driver_string(const struct device *dev);
 
+void dev_warn_deferred(struct device *dev, const char *fmt, ...);
 
 #ifdef CONFIG_PRINTK
 


-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Mark Brown wrote:

> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> 
> > Furthermore, that applies only to devices that use synchronous suspend.  
> > Async suspend is becoming common, and there the only restrictions are 
> > parent-child relations plus whatever explicit requirements that drivers 
> > impose by calling device_pm_wait_for_dev().
> 
> Hrm, this is the first I'd noticed that feature though I see the initial
> commit dates from January.

Async suspend and device_pm_wait_for_dev() were added in January 2010, 
not 2015!

>  It looks like most of the users are PCs at
> the minute but we should be using it more widely for embedded things,
> there's definitely some cases I'm aware of where it will allow us to
> remove some open coding.
> 
> It does seem like we want to be feeding dependency information we
> discover for probing way into the suspend dependencies...

Rafael has been thinking about a way to do this systematically.  
Nothing concrete has emerged yet.

Alan Stern

Re: [GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Mark Brown wrote:

> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> 
> > Furthermore, that applies only to devices that use synchronous suspend.  
> > Async suspend is becoming common, and there the only restrictions are 
> > parent-child relations plus whatever explicit requirements that drivers 
> > impose by calling device_pm_wait_for_dev().
> 
> Hrm, this is the first I'd noticed that feature though I see the initial
> commit dates from January.

Async suspend and device_pm_wait_for_dev() were added in January 2010, 
not 2015!

>  It looks like most of the users are PCs at
> the minute but we should be using it more widely for embedded things,
> there's definitely some cases I'm aware of where it will allow us to
> remove some open coding.
> 
> It does seem like we want to be feeding dependency information we
> discover for probing way into the suspend dependencies...

Rafael has been thinking about a way to do this systematically.  
Nothing concrete has emerged yet.

Alan Stern

Re: [GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Mark Brown wrote:

> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> 
> > Furthermore, that applies only to devices that use synchronous suspend.  
> > Async suspend is becoming common, and there the only restrictions are 
> > parent-child relations plus whatever explicit requirements that drivers 
> > impose by calling device_pm_wait_for_dev().
> 
> Hrm, this is the first I'd noticed that feature though I see the initial
> commit dates from January.

Async suspend and device_pm_wait_for_dev() were added in January 2010, 
not 2015!

>  It looks like most of the users are PCs at
> the minute but we should be using it more widely for embedded things,
> there's definitely some cases I'm aware of where it will allow us to
> remove some open coding.
> 
> It does seem like we want to be feeding dependency information we
> discover for probing way into the suspend dependencies...

Rafael has been thinking about a way to do this systematically.  
Nothing concrete has emerged yet.

Alan Stern

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
>
>> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>>
>> > Furthermore, that applies only to devices that use synchronous suspend.
>> > Async suspend is becoming common, and there the only restrictions are
>> > parent-child relations plus whatever explicit requirements that drivers
>> > impose by calling device_pm_wait_for_dev().
>>
>> Hrm, this is the first I'd noticed that feature though I see the initial
>> commit dates from January.
>
> Async suspend and device_pm_wait_for_dev() were added in January 2010,
> not 2015!
>
>>  It looks like most of the users are PCs at
>> the minute but we should be using it more widely for embedded things,
>> there's definitely some cases I'm aware of where it will allow us to
>> remove some open coding.
>>
>> It does seem like we want to be feeding dependency information we
>> discover for probing way into the suspend dependencies...
>
> Rafael has been thinking about a way to do this systematically.
> Nothing concrete has emerged yet.

This iteration of the series would make this quite easy, as
dependencies are calculated before probes are attempted:

https://lkml.org/lkml/2015/6/17/311

Regards,

Tomeu

> Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
>
>> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>>
>> > Furthermore, that applies only to devices that use synchronous suspend.
>> > Async suspend is becoming common, and there the only restrictions are
>> > parent-child relations plus whatever explicit requirements that drivers
>> > impose by calling device_pm_wait_for_dev().
>>
>> Hrm, this is the first I'd noticed that feature though I see the initial
>> commit dates from January.
>
> Async suspend and device_pm_wait_for_dev() were added in January 2010,
> not 2015!
>
>>  It looks like most of the users are PCs at
>> the minute but we should be using it more widely for embedded things,
>> there's definitely some cases I'm aware of where it will allow us to
>> remove some open coding.
>>
>> It does seem like we want to be feeding dependency information we
>> discover for probing way into the suspend dependencies...
>
> Rafael has been thinking about a way to do this systematically.
> Nothing concrete has emerged yet.

This iteration of the series would make this quite easy, as
dependencies are calculated before probes are attempted:

https://lkml.org/lkml/2015/6/17/311

Regards,

Tomeu

> Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
>
>> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>>
>> > Furthermore, that applies only to devices that use synchronous suspend.
>> > Async suspend is becoming common, and there the only restrictions are
>> > parent-child relations plus whatever explicit requirements that drivers
>> > impose by calling device_pm_wait_for_dev().
>>
>> Hrm, this is the first I'd noticed that feature though I see the initial
>> commit dates from January.
>
> Async suspend and device_pm_wait_for_dev() were added in January 2010,
> not 2015!
>
>>  It looks like most of the users are PCs at
>> the minute but we should be using it more widely for embedded things,
>> there's definitely some cases I'm aware of where it will allow us to
>> remove some open coding.
>>
>> It does seem like we want to be feeding dependency information we
>> discover for probing way into the suspend dependencies...
>
> Rafael has been thinking about a way to do this systematically.
> Nothing concrete has emerged yet.

This iteration of the series would make this quite easy, as
dependencies are calculated before probes are attempted:

https://lkml.org/lkml/2015/6/17/311

Regards,

Tomeu

> Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Tomeu Vizoso wrote:

> On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Tue, 20 Oct 2015, Mark Brown wrote:
> >
> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >>
> >> > Furthermore, that applies only to devices that use synchronous suspend.
> >> > Async suspend is becoming common, and there the only restrictions are
> >> > parent-child relations plus whatever explicit requirements that drivers
> >> > impose by calling device_pm_wait_for_dev().
> >>
> >> Hrm, this is the first I'd noticed that feature though I see the initial
> >> commit dates from January.
> >
> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
> > not 2015!
> >
> >>  It looks like most of the users are PCs at
> >> the minute but we should be using it more widely for embedded things,
> >> there's definitely some cases I'm aware of where it will allow us to
> >> remove some open coding.
> >>
> >> It does seem like we want to be feeding dependency information we
> >> discover for probing way into the suspend dependencies...
> >
> > Rafael has been thinking about a way to do this systematically.
> > Nothing concrete has emerged yet.
> 
> This iteration of the series would make this quite easy, as
> dependencies are calculated before probes are attempted:
> 
> https://lkml.org/lkml/2015/6/17/311

But what Rafael is proposing is quite general; it would apply to _all_
dependencies as opposed to just those present in DT drivers or those 
affecting platform_devices.

Alan Stern

Re: [GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Tomeu Vizoso wrote:

> On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Tue, 20 Oct 2015, Mark Brown wrote:
> >
> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >>
> >> > Furthermore, that applies only to devices that use synchronous suspend.
> >> > Async suspend is becoming common, and there the only restrictions are
> >> > parent-child relations plus whatever explicit requirements that drivers
> >> > impose by calling device_pm_wait_for_dev().
> >>
> >> Hrm, this is the first I'd noticed that feature though I see the initial
> >> commit dates from January.
> >
> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
> > not 2015!
> >
> >>  It looks like most of the users are PCs at
> >> the minute but we should be using it more widely for embedded things,
> >> there's definitely some cases I'm aware of where it will allow us to
> >> remove some open coding.
> >>
> >> It does seem like we want to be feeding dependency information we
> >> discover for probing way into the suspend dependencies...
> >
> > Rafael has been thinking about a way to do this systematically.
> > Nothing concrete has emerged yet.
> 
> This iteration of the series would make this quite easy, as
> dependencies are calculated before probes are attempted:
> 
> https://lkml.org/lkml/2015/6/17/311

But what Rafael is proposing is quite general; it would apply to _all_
dependencies as opposed to just those present in DT drivers or those 
affecting platform_devices.

Alan Stern

Re: [GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Tomeu Vizoso wrote:

> On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Tue, 20 Oct 2015, Mark Brown wrote:
> >
> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >>
> >> > Furthermore, that applies only to devices that use synchronous suspend.
> >> > Async suspend is becoming common, and there the only restrictions are
> >> > parent-child relations plus whatever explicit requirements that drivers
> >> > impose by calling device_pm_wait_for_dev().
> >>
> >> Hrm, this is the first I'd noticed that feature though I see the initial
> >> commit dates from January.
> >
> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
> > not 2015!
> >
> >>  It looks like most of the users are PCs at
> >> the minute but we should be using it more widely for embedded things,
> >> there's definitely some cases I'm aware of where it will allow us to
> >> remove some open coding.
> >>
> >> It does seem like we want to be feeding dependency information we
> >> discover for probing way into the suspend dependencies...
> >
> > Rafael has been thinking about a way to do this systematically.
> > Nothing concrete has emerged yet.
> 
> This iteration of the series would make this quite easy, as
> dependencies are calculated before probes are attempted:
> 
> https://lkml.org/lkml/2015/6/17/311

But what Rafael is proposing is quite general; it would apply to _all_
dependencies as opposed to just those present in DT drivers or those 
affecting platform_devices.

Alan Stern

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> On Tue, 20 Oct 2015, Tomeu Vizoso wrote:

> > This iteration of the series would make this quite easy, as
> > dependencies are calculated before probes are attempted:

> > https://lkml.org/lkml/2015/6/17/311

> But what Rafael is proposing is quite general; it would apply to _all_
> dependencies as opposed to just those present in DT drivers or those 
> affecting platform_devices.

We'll still need most of the DT bits that are there at the minute (the
ones strewn around the subsystems) AFAICT since it's at the point where
we parse the DT and work out what the dependencies are which we probably
want to do prior to getting the drivers up and will be different for
ACPI.  I think the level of DT dependency here looks a lot larger than
it actually is due to the fact that a lot of what's being modified is DT
parsing code.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> On Tue, 20 Oct 2015, Tomeu Vizoso wrote:

> > This iteration of the series would make this quite easy, as
> > dependencies are calculated before probes are attempted:

> > https://lkml.org/lkml/2015/6/17/311

> But what Rafael is proposing is quite general; it would apply to _all_
> dependencies as opposed to just those present in DT drivers or those 
> affecting platform_devices.

We'll still need most of the DT bits that are there at the minute (the
ones strewn around the subsystems) AFAICT since it's at the point where
we parse the DT and work out what the dependencies are which we probably
want to do prior to getting the drivers up and will be different for
ACPI.  I think the level of DT dependency here looks a lot larger than
it actually is due to the fact that a lot of what's being modified is DT
parsing code.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> On Tue, 20 Oct 2015, Tomeu Vizoso wrote:

> > This iteration of the series would make this quite easy, as
> > dependencies are calculated before probes are attempted:

> > https://lkml.org/lkml/2015/6/17/311

> But what Rafael is proposing is quite general; it would apply to _all_
> dependencies as opposed to just those present in DT drivers or those 
> affecting platform_devices.

We'll still need most of the DT bits that are there at the minute (the
ones strewn around the subsystems) AFAICT since it's at the point where
we parse the DT and work out what the dependencies are which we probably
want to do prior to getting the drivers up and will be different for
ACPI.  I think the level of DT dependency here looks a lot larger than
it actually is due to the fact that a lot of what's being modified is DT
parsing code.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> >> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> >> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> >> >> > But the point I'm making is that we are working towards *fixing* that,
> >> >> >> > and *not* using DT-specific code in places where we should be using the
> >> >> >> > generic APIs.
> >> >> >>
> >> >> >> What is the plan for fixing things here?  It's not obvious (at least to
> >> >> >> me) that we don't want to have the subsystems having knowledge of how
> >> >> >> they are bound to a specific firmware which is what you seem to imply
> >> >> >> here.
> >> >> >
> >> >> > I don't know that there *is* a coherent plan here to address it all.
> >> >> >
> >> >> > Certainly, we *will* need subsystems to have firmware-specific
> >> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> >> >> > describe GPIO, and properties which reference GPIO pins are intended to
> >> >> > work through that — while in DT, properties which reference GPIO pins
> >> >> > will have different contents. They'll be compatible at the driver
> >> >> > level, in the sense that there's a call to get a given GPIO given the
> >> >> > property name, but the subsystems *will* be doing different things
> >> >> > behind the scenes.
> >> >> >
> >> >> > My plan, such as it is, is to go through the leaf-node drivers which
> >> >> > almost definitely *should* be firmware-agnostic, and convert those. And
> >> >> > then take stock of what we have left, and work out what, if anything,
> >> >> > still needs to be done.
> >> >>
> >> >> Many cases are already agnostic in the drivers in terms of the *_get()
> >> >> functions. Some are DT specific, but probably because those subsystems
> >> >> are new and DT only. In any case, I don't think these 1 line changes
> >> >> do anything to make doing conversions here harder.
> >> >>
> >> >> >> It seems like we're going to have to refactor these bits of code when
> >> >> >> they get generalised anyway so I'm not sure that the additional cost
> >> >> >> here is that big.
> >> >> >
> >> >> > That's an acceptable answer — "we're adding legacy code here but we
> >> >> > know it's going to be refactored anyway". If that's true, all it takes
> >> >> > is a note in the commit comment to that effect. That's different from
> >> >> > having not thought about it :)
> >> >>
> >> >> Considering at one point we did create a fwnode based API, we did
> >> >> think about it. Plus there was little input from ACPI folks as to
> >> >> whether the change was even useful for ACPI case.
> >> >
> >> > Well, sorry, but who was asking whom, specifically?
> >>
> >> You and linux-acpi have been copied on v2 and later of the entire
> >> series I think.
> >
> > Yes, but it wasn't like a direct request, say "We need your input, so can you
> > please have a look and BTW we want this in 4.4, so please do it ASAP".  In
> > which case I'd prioritize that before other things I needed to take care of.
> 
> Fair enough. Can you please review and comment on v7 of the series? We
> can discuss at KS as well.

I'll do that.

I'm in the middle of travel right now and speaking at a conference tomorrow,
so I may not be able to get to that for a couple of days, but will do my best
to do it as soon as I possibly can.

> >> > The underlying problem is present in ACPI too and we don't really have a good
> >> > solution for it.  We might benefit from a common one if it existed.
> >>
> >> The problem for DT is we don't generically know what are the
> >> dependencies at a core level. We could know some or most dependencies
> >> if phandles (links to other nodes) were typed, but they are not. If
> >> the core had this information, we could simply control the device
> >> creation to order probing. Instead, this information is encoded into
> >> the bindings and binding parsing resides in the subsystems. That
> >> parsing happens during probe of the client side and is done by the
> >> subsystems (for common bindings). Since we already do the parsing at
> >> this point, it is a convenient place to trigger the probe of the
> >> dependency. Is ACPI going to be similar in this regard?
> >
> > It is similar in some ways.  For example, if a device's functionality depends
> > on an I2C resource (connection), the core doesn't know that at the device
> > creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.
> 
> So you will need to create devices, defer their probing and then probe
> on demand as well unless you have other ideas how you would do it.

Right.

> > There is a _DEP object in ACPI that can be used by firmware to tell the OS
> > about those dependencies, but there's no way in the driver core to use that
> > information anyway today.
> 
> I would think that the equivalent function for ACPI to of_device_probe
> could process these if they are generic and you can associate the
> dependency to a struct device.

Well, something along these lines probably.

> >> Fundamentally, it is a question of probe devices when their
> >> dependencies are present or drivers ensure their dependencies are
> >> ready. IIRC, init systems went thru a similar debate for service
> >> dependencies.
> >
> > The probe ordering is not the entire picture, though.
> >
> > Even if you get the probe ordering right, the problem is going to show up in
> > multiple other places: system suspend/resume, runtime PM, system shutdown,
> > unbinding of drivers.  In all of those cases it is necessary to handle things
> > in a specific order if there is a dependency.
> 
> My understanding was with deferred probe that it also solves suspend
> ordering problems because things are suspended in reverse order of
> probing. I suppose you could have slightly different dependencies for
> suspend, runtime PM, etc. than for probe? Perhaps we need to save the
> list of dependencies as we probe them. I don't think that would be too
> hard to add on to this series, but then if we don't need it now, why
> add it?

As Alan said, there are two problems here.  First off, the ordering of the
list used by system suspend/resume is the registration ordering, not the
probe ordering.  Moreover, though, even if we get the ordering right, it
still is not sufficient for devices with async_suspend set.

To address this, the core will have to make the involved async threads wait
for each other in accordance with the dependencies too.  That, in turn, is
very close to what's needed for runtime PM.

> >> >> In any case, we're talking about adding 1 line.
> >> >
> >> > But also about making the driver core slighly OF-centric.
> >>
> >> How so? The one line is in DT binding parsing code in subsystems, not
> >> driver core. The driver core change is we add every device (that
> >> happened to be created by DT) to the deferred probe list, so they
> >> don't probe right away.
> >
> > The "that happened to be created by DT" part is of concern here.  What is there
> > that makes DT special in that respect?  Why shouldn't that be applicable to
> > devices created by the ACPI core, for example, or by a board file or something
> > else?
> 
> DT is first. I think both examples could use this. Board files avoid
> the problem by controlling the registration order with initcall levels
> and just the call order in the code. You could come up with some way
> to define dependencies for devices in board files and reuse this
> mechanism. ACPI could use this as well if the dependencies are handled
> in a similar way and it seems like they could be.
> 
> >> > Sure, we need OF-specific code and ACPI-specific code wherever different
> >> > handling is required, but doing that at the driver core level seems to be
> >> > a bit of a stretch to me.
> >> >
> >> > Please note that we don't really have ACPI-specific calls in the driver core,
> >> > although we might have added them long ago even before the OF stuff appeared
> >> > in the kernel for the first time.  We didn't do that, (among other things)
> >> > because we didn't want that particular firmware interface to appear special
> >> > in any way and I'm not really sure why it is now OK to make OF look special
> >> > instead.
> >>
> >> I don't think DT is special and we avoid DT specific core changes as
> >> much as possible. I think the difference is DT uses platform_device
> >> and ACPI does not.
> >
> > ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
> > platform devices by default now.
> 
> Okay, I should have grepped for that:
> drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev, NULL);
> drivers/base/platform.c:        len = acpi_device_modalias(dev, buf,
> PAGE_SIZE -1);
> drivers/base/platform.c:        rc = acpi_device_uevent_modalias(dev, env);
> drivers/base/platform.c:        /* Then try ACPI style match */
> drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv))
> 
> These are all cases which have DT version as well, so we're not really
> all that different here. There's a few more for DT, but that probably
> means you have just not hit the problems we have yet. For example,
> what happens if you have an interrupt line in which the controller is
> probed after the device connected to the interrupt line? That required
> resolving irqs in platform_get_irq rather than using static resources
> to support deferred probe.

We don't have this particular problem, because the IRQ controllers are
enumerated in a special way.

> Converting things like this to fwnode calls isn't hard to do. There
> just hasn't been a pressing need or mandate to do so.

Well, to me the problem is actually generic, so it is better to use generic
concepts to start with when trying to address it where that doesn't add too
much overhead.  Otherwise it's very easy to lose the broader context from
one's sight and then to start cutting corners.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> >> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> >> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> >> >> > But the point I'm making is that we are working towards *fixing* that,
> >> >> >> > and *not* using DT-specific code in places where we should be using the
> >> >> >> > generic APIs.
> >> >> >>
> >> >> >> What is the plan for fixing things here?  It's not obvious (at least to
> >> >> >> me) that we don't want to have the subsystems having knowledge of how
> >> >> >> they are bound to a specific firmware which is what you seem to imply
> >> >> >> here.
> >> >> >
> >> >> > I don't know that there *is* a coherent plan here to address it all.
> >> >> >
> >> >> > Certainly, we *will* need subsystems to have firmware-specific
> >> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> >> >> > describe GPIO, and properties which reference GPIO pins are intended to
> >> >> > work through that — while in DT, properties which reference GPIO pins
> >> >> > will have different contents. They'll be compatible at the driver
> >> >> > level, in the sense that there's a call to get a given GPIO given the
> >> >> > property name, but the subsystems *will* be doing different things
> >> >> > behind the scenes.
> >> >> >
> >> >> > My plan, such as it is, is to go through the leaf-node drivers which
> >> >> > almost definitely *should* be firmware-agnostic, and convert those. And
> >> >> > then take stock of what we have left, and work out what, if anything,
> >> >> > still needs to be done.
> >> >>
> >> >> Many cases are already agnostic in the drivers in terms of the *_get()
> >> >> functions. Some are DT specific, but probably because those subsystems
> >> >> are new and DT only. In any case, I don't think these 1 line changes
> >> >> do anything to make doing conversions here harder.
> >> >>
> >> >> >> It seems like we're going to have to refactor these bits of code when
> >> >> >> they get generalised anyway so I'm not sure that the additional cost
> >> >> >> here is that big.
> >> >> >
> >> >> > That's an acceptable answer — "we're adding legacy code here but we
> >> >> > know it's going to be refactored anyway". If that's true, all it takes
> >> >> > is a note in the commit comment to that effect. That's different from
> >> >> > having not thought about it :)
> >> >>
> >> >> Considering at one point we did create a fwnode based API, we did
> >> >> think about it. Plus there was little input from ACPI folks as to
> >> >> whether the change was even useful for ACPI case.
> >> >
> >> > Well, sorry, but who was asking whom, specifically?
> >>
> >> You and linux-acpi have been copied on v2 and later of the entire
> >> series I think.
> >
> > Yes, but it wasn't like a direct request, say "We need your input, so can you
> > please have a look and BTW we want this in 4.4, so please do it ASAP".  In
> > which case I'd prioritize that before other things I needed to take care of.
> 
> Fair enough. Can you please review and comment on v7 of the series? We
> can discuss at KS as well.

I'll do that.

I'm in the middle of travel right now and speaking at a conference tomorrow,
so I may not be able to get to that for a couple of days, but will do my best
to do it as soon as I possibly can.

> >> > The underlying problem is present in ACPI too and we don't really have a good
> >> > solution for it.  We might benefit from a common one if it existed.
> >>
> >> The problem for DT is we don't generically know what are the
> >> dependencies at a core level. We could know some or most dependencies
> >> if phandles (links to other nodes) were typed, but they are not. If
> >> the core had this information, we could simply control the device
> >> creation to order probing. Instead, this information is encoded into
> >> the bindings and binding parsing resides in the subsystems. That
> >> parsing happens during probe of the client side and is done by the
> >> subsystems (for common bindings). Since we already do the parsing at
> >> this point, it is a convenient place to trigger the probe of the
> >> dependency. Is ACPI going to be similar in this regard?
> >
> > It is similar in some ways.  For example, if a device's functionality depends
> > on an I2C resource (connection), the core doesn't know that at the device
> > creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.
> 
> So you will need to create devices, defer their probing and then probe
> on demand as well unless you have other ideas how you would do it.

Right.

> > There is a _DEP object in ACPI that can be used by firmware to tell the OS
> > about those dependencies, but there's no way in the driver core to use that
> > information anyway today.
> 
> I would think that the equivalent function for ACPI to of_device_probe
> could process these if they are generic and you can associate the
> dependency to a struct device.

Well, something along these lines probably.

> >> Fundamentally, it is a question of probe devices when their
> >> dependencies are present or drivers ensure their dependencies are
> >> ready. IIRC, init systems went thru a similar debate for service
> >> dependencies.
> >
> > The probe ordering is not the entire picture, though.
> >
> > Even if you get the probe ordering right, the problem is going to show up in
> > multiple other places: system suspend/resume, runtime PM, system shutdown,
> > unbinding of drivers.  In all of those cases it is necessary to handle things
> > in a specific order if there is a dependency.
> 
> My understanding was with deferred probe that it also solves suspend
> ordering problems because things are suspended in reverse order of
> probing. I suppose you could have slightly different dependencies for
> suspend, runtime PM, etc. than for probe? Perhaps we need to save the
> list of dependencies as we probe them. I don't think that would be too
> hard to add on to this series, but then if we don't need it now, why
> add it?

As Alan said, there are two problems here.  First off, the ordering of the
list used by system suspend/resume is the registration ordering, not the
probe ordering.  Moreover, though, even if we get the ordering right, it
still is not sufficient for devices with async_suspend set.

To address this, the core will have to make the involved async threads wait
for each other in accordance with the dependencies too.  That, in turn, is
very close to what's needed for runtime PM.

> >> >> In any case, we're talking about adding 1 line.
> >> >
> >> > But also about making the driver core slighly OF-centric.
> >>
> >> How so? The one line is in DT binding parsing code in subsystems, not
> >> driver core. The driver core change is we add every device (that
> >> happened to be created by DT) to the deferred probe list, so they
> >> don't probe right away.
> >
> > The "that happened to be created by DT" part is of concern here.  What is there
> > that makes DT special in that respect?  Why shouldn't that be applicable to
> > devices created by the ACPI core, for example, or by a board file or something
> > else?
> 
> DT is first. I think both examples could use this. Board files avoid
> the problem by controlling the registration order with initcall levels
> and just the call order in the code. You could come up with some way
> to define dependencies for devices in board files and reuse this
> mechanism. ACPI could use this as well if the dependencies are handled
> in a similar way and it seems like they could be.
> 
> >> > Sure, we need OF-specific code and ACPI-specific code wherever different
> >> > handling is required, but doing that at the driver core level seems to be
> >> > a bit of a stretch to me.
> >> >
> >> > Please note that we don't really have ACPI-specific calls in the driver core,
> >> > although we might have added them long ago even before the OF stuff appeared
> >> > in the kernel for the first time.  We didn't do that, (among other things)
> >> > because we didn't want that particular firmware interface to appear special
> >> > in any way and I'm not really sure why it is now OK to make OF look special
> >> > instead.
> >>
> >> I don't think DT is special and we avoid DT specific core changes as
> >> much as possible. I think the difference is DT uses platform_device
> >> and ACPI does not.
> >
> > ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
> > platform devices by default now.
> 
> Okay, I should have grepped for that:
> drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev, NULL);
> drivers/base/platform.c:        len = acpi_device_modalias(dev, buf,
> PAGE_SIZE -1);
> drivers/base/platform.c:        rc = acpi_device_uevent_modalias(dev, env);
> drivers/base/platform.c:        /* Then try ACPI style match */
> drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv))
> 
> These are all cases which have DT version as well, so we're not really
> all that different here. There's a few more for DT, but that probably
> means you have just not hit the problems we have yet. For example,
> what happens if you have an interrupt line in which the controller is
> probed after the device connected to the interrupt line? That required
> resolving irqs in platform_get_irq rather than using static resources
> to support deferred probe.

We don't have this particular problem, because the IRQ controllers are
enumerated in a special way.

> Converting things like this to fwnode calls isn't hard to do. There
> just hasn't been a pressing need or mandate to do so.

Well, to me the problem is actually generic, so it is better to use generic
concepts to start with when trying to address it where that doesn't add too
much overhead.  Otherwise it's very easy to lose the broader context from
one's sight and then to start cutting corners.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net=
> wrote:
> > On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.=
net> wrote:
> >> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> >> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infrad=
ead.org> wrote:
> >> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> >> >> > But the point I'm making is that we are working towards *f=
ixing* that,
> >> >> >> > and *not* using DT-specific code in places where we should=
 be using the
> >> >> >> > generic APIs.
> >> >> >>
> >> >> >> What is the plan for fixing things here?  It's not obvious (=
at least to
> >> >> >> me) that we don't want to have the subsystems having knowled=
ge of how
> >> >> >> they are bound to a specific firmware which is what you seem=
 to imply
> >> >> >> here.
> >> >> >
> >> >> > I don't know that there *is* a coherent plan here to address =
it all.
> >> >> >
> >> >> > Certainly, we *will* need subsystems to have firmware-specifi=
c
> >> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* =
a way to
> >> >> > describe GPIO, and properties which reference GPIO pins are i=
ntended to
> >> >> > work through that =E2=80=94 while in DT, properties which ref=
erence GPIO pins
> >> >> > will have different contents. They'll be compatible at the dr=
iver
> >> >> > level, in the sense that there's a call to get a given GPIO g=
iven the
> >> >> > property name, but the subsystems *will* be doing different t=
hings
> >> >> > behind the scenes.
> >> >> >
> >> >> > My plan, such as it is, is to go through the leaf-node driver=
s which
> >> >> > almost definitely *should* be firmware-agnostic, and convert =
those. And
> >> >> > then take stock of what we have left, and work out what, if a=
nything,
> >> >> > still needs to be done.
> >> >>
> >> >> Many cases are already agnostic in the drivers in terms of the =
*_get()
> >> >> functions. Some are DT specific, but probably because those sub=
systems
> >> >> are new and DT only. In any case, I don't think these 1 line ch=
anges
> >> >> do anything to make doing conversions here harder.
> >> >>
> >> >> >> It seems like we're going to have to refactor these bits of =
code when
> >> >> >> they get generalised anyway so I'm not sure that the additio=
nal cost
> >> >> >> here is that big.
> >> >> >
> >> >> > That's an acceptable answer =E2=80=94 "we're adding legacy co=
de here but we
> >> >> > know it's going to be refactored anyway". If that's true, all=
 it takes
> >> >> > is a note in the commit comment to that effect. That's differ=
ent from
> >> >> > having not thought about it :)
> >> >>
> >> >> Considering at one point we did create a fwnode based API, we d=
id
> >> >> think about it. Plus there was little input from ACPI folks as =
to
> >> >> whether the change was even useful for ACPI case.
> >> >
> >> > Well, sorry, but who was asking whom, specifically?
> >>
> >> You and linux-acpi have been copied on v2 and later of the entire
> >> series I think.
> >
> > Yes, but it wasn't like a direct request, say "We need your input, =
so can you
> > please have a look and BTW we want this in 4.4, so please do it ASA=
P".  In
> > which case I'd prioritize that before other things I needed to take=
 care of.
>=20
> Fair enough. Can you please review and comment on v7 of the series? W=
e
> can discuss at KS as well.

I'll do that.

I'm in the middle of travel right now and speaking at a conference tomo=
rrow,
so I may not be able to get to that for a couple of days, but will do m=
y best
to do it as soon as I possibly can.

> >> > The underlying problem is present in ACPI too and we don't reall=
y have a good
> >> > solution for it.  We might benefit from a common one if it exist=
ed.
> >>
> >> The problem for DT is we don't generically know what are the
> >> dependencies at a core level. We could know some or most dependenc=
ies
> >> if phandles (links to other nodes) were typed, but they are not. I=
f
> >> the core had this information, we could simply control the device
> >> creation to order probing. Instead, this information is encoded in=
to
> >> the bindings and binding parsing resides in the subsystems. That
> >> parsing happens during probe of the client side and is done by the=

> >> subsystems (for common bindings). Since we already do the parsing =
at
> >> this point, it is a convenient place to trigger the probe of the
> >> dependency. Is ACPI going to be similar in this regard?
> >
> > It is similar in some ways.  For example, if a device's functionali=
ty depends
> > on an I2C resource (connection), the core doesn't know that at the =
device
> > creation time at least in some cases.  Same for GPIO, SPI, DMA engi=
nes etc.
>=20
> So you will need to create devices, defer their probing and then prob=
e
> on demand as well unless you have other ideas how you would do it.

Right.

> > There is a _DEP object in ACPI that can be used by firmware to tell=
 the OS
> > about those dependencies, but there's no way in the driver core to =
use that
> > information anyway today.
>=20
> I would think that the equivalent function for ACPI to of_device_prob=
e
> could process these if they are generic and you can associate the
> dependency to a struct device.

Well, something along these lines probably.

> >> Fundamentally, it is a question of probe devices when their
> >> dependencies are present or drivers ensure their dependencies are
> >> ready. IIRC, init systems went thru a similar debate for service
> >> dependencies.
> >
> > The probe ordering is not the entire picture, though.
> >
> > Even if you get the probe ordering right, the problem is going to s=
how up in
> > multiple other places: system suspend/resume, runtime PM, system sh=
utdown,
> > unbinding of drivers.  In all of those cases it is necessary to han=
dle things
> > in a specific order if there is a dependency.
>=20
> My understanding was with deferred probe that it also solves suspend
> ordering problems because things are suspended in reverse order of
> probing. I suppose you could have slightly different dependencies for=

> suspend, runtime PM, etc. than for probe? Perhaps we need to save the=

> list of dependencies as we probe them. I don't think that would be to=
o
> hard to add on to this series, but then if we don't need it now, why
> add it?

As Alan said, there are two problems here.  First off, the ordering of =
the
list used by system suspend/resume is the registration ordering, not th=
e
probe ordering.  Moreover, though, even if we get the ordering right, i=
t
still is not sufficient for devices with async_suspend set.

To address this, the core will have to make the involved async threads =
wait
for each other in accordance with the dependencies too.  That, in turn,=
 is
very close to what's needed for runtime PM.

> >> >> In any case, we're talking about adding 1 line.
> >> >
> >> > But also about making the driver core slighly OF-centric.
> >>
> >> How so? The one line is in DT binding parsing code in subsystems, =
not
> >> driver core. The driver core change is we add every device (that
> >> happened to be created by DT) to the deferred probe list, so they
> >> don't probe right away.
> >
> > The "that happened to be created by DT" part is of concern here.  W=
hat is there
> > that makes DT special in that respect?  Why shouldn't that be appli=
cable to
> > devices created by the ACPI core, for example, or by a board file o=
r something
> > else?
>=20
> DT is first. I think both examples could use this. Board files avoid
> the problem by controlling the registration order with initcall level=
s
> and just the call order in the code. You could come up with some way
> to define dependencies for devices in board files and reuse this
> mechanism. ACPI could use this as well if the dependencies are handle=
d
> in a similar way and it seems like they could be.
>=20
> >> > Sure, we need OF-specific code and ACPI-specific code wherever d=
ifferent
> >> > handling is required, but doing that at the driver core level se=
ems to be
> >> > a bit of a stretch to me.
> >> >
> >> > Please note that we don't really have ACPI-specific calls in the=
 driver core,
> >> > although we might have added them long ago even before the OF st=
uff appeared
> >> > in the kernel for the first time.  We didn't do that, (among oth=
er things)
> >> > because we didn't want that particular firmware interface to app=
ear special
> >> > in any way and I'm not really sure why it is now OK to make OF l=
ook special
> >> > instead.
> >>
> >> I don't think DT is special and we avoid DT specific core changes =
as
> >> much as possible. I think the difference is DT uses platform_devic=
e
> >> and ACPI does not.
> >
> > ACPI uses platform devices too.  In fact, ACPI device objects are e=
numerated as
> > platform devices by default now.
>=20
> Okay, I should have grepped for that:
> drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev=
, NULL);
> drivers/base/platform.c:        len =3D acpi_device_modalias(dev, buf=
,
> PAGE_SIZE -1);
> drivers/base/platform.c:        rc =3D acpi_device_uevent_modalias(de=
v, env);
> drivers/base/platform.c:        /* Then try ACPI style match */
> drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv=
))
>=20
> These are all cases which have DT version as well, so we're not reall=
y
> all that different here. There's a few more for DT, but that probably=

> means you have just not hit the problems we have yet. For example,
> what happens if you have an interrupt line in which the controller is=

> probed after the device connected to the interrupt line? That require=
d
> resolving irqs in platform_get_irq rather than using static resources=

> to support deferred probe.

We don't have this particular problem, because the IRQ controllers are
enumerated in a special way.

> Converting things like this to fwnode calls isn't hard to do. There
> just hasn't been a pressing need or mandate to do so.

Well, to me the problem is actually generic, so it is better to use gen=
eric
concepts to start with when trying to address it where that doesn't add=
 too
much overhead.  Otherwise it's very easy to lose the broader context fr=
om
one's sight and then to start cutting corners.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> >> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> >> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> >> >> > But the point I'm making is that we are working towards *fixing* that,
> >> >> >> > and *not* using DT-specific code in places where we should be using the
> >> >> >> > generic APIs.
> >> >> >>
> >> >> >> What is the plan for fixing things here?  It's not obvious (at least to
> >> >> >> me) that we don't want to have the subsystems having knowledge of how
> >> >> >> they are bound to a specific firmware which is what you seem to imply
> >> >> >> here.
> >> >> >
> >> >> > I don't know that there *is* a coherent plan here to address it all.
> >> >> >
> >> >> > Certainly, we *will* need subsystems to have firmware-specific
> >> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> >> >> > describe GPIO, and properties which reference GPIO pins are intended to
> >> >> > work through that — while in DT, properties which reference GPIO pins
> >> >> > will have different contents. They'll be compatible at the driver
> >> >> > level, in the sense that there's a call to get a given GPIO given the
> >> >> > property name, but the subsystems *will* be doing different things
> >> >> > behind the scenes.
> >> >> >
> >> >> > My plan, such as it is, is to go through the leaf-node drivers which
> >> >> > almost definitely *should* be firmware-agnostic, and convert those. And
> >> >> > then take stock of what we have left, and work out what, if anything,
> >> >> > still needs to be done.
> >> >>
> >> >> Many cases are already agnostic in the drivers in terms of the *_get()
> >> >> functions. Some are DT specific, but probably because those subsystems
> >> >> are new and DT only. In any case, I don't think these 1 line changes
> >> >> do anything to make doing conversions here harder.
> >> >>
> >> >> >> It seems like we're going to have to refactor these bits of code when
> >> >> >> they get generalised anyway so I'm not sure that the additional cost
> >> >> >> here is that big.
> >> >> >
> >> >> > That's an acceptable answer — "we're adding legacy code here but we
> >> >> > know it's going to be refactored anyway". If that's true, all it takes
> >> >> > is a note in the commit comment to that effect. That's different from
> >> >> > having not thought about it :)
> >> >>
> >> >> Considering at one point we did create a fwnode based API, we did
> >> >> think about it. Plus there was little input from ACPI folks as to
> >> >> whether the change was even useful for ACPI case.
> >> >
> >> > Well, sorry, but who was asking whom, specifically?
> >>
> >> You and linux-acpi have been copied on v2 and later of the entire
> >> series I think.
> >
> > Yes, but it wasn't like a direct request, say "We need your input, so can you
> > please have a look and BTW we want this in 4.4, so please do it ASAP".  In
> > which case I'd prioritize that before other things I needed to take care of.
> 
> Fair enough. Can you please review and comment on v7 of the series? We
> can discuss at KS as well.

I'll do that.

I'm in the middle of travel right now and speaking at a conference tomorrow,
so I may not be able to get to that for a couple of days, but will do my best
to do it as soon as I possibly can.

> >> > The underlying problem is present in ACPI too and we don't really have a good
> >> > solution for it.  We might benefit from a common one if it existed.
> >>
> >> The problem for DT is we don't generically know what are the
> >> dependencies at a core level. We could know some or most dependencies
> >> if phandles (links to other nodes) were typed, but they are not. If
> >> the core had this information, we could simply control the device
> >> creation to order probing. Instead, this information is encoded into
> >> the bindings and binding parsing resides in the subsystems. That
> >> parsing happens during probe of the client side and is done by the
> >> subsystems (for common bindings). Since we already do the parsing at
> >> this point, it is a convenient place to trigger the probe of the
> >> dependency. Is ACPI going to be similar in this regard?
> >
> > It is similar in some ways.  For example, if a device's functionality depends
> > on an I2C resource (connection), the core doesn't know that at the device
> > creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.
> 
> So you will need to create devices, defer their probing and then probe
> on demand as well unless you have other ideas how you would do it.

Right.

> > There is a _DEP object in ACPI that can be used by firmware to tell the OS
> > about those dependencies, but there's no way in the driver core to use that
> > information anyway today.
> 
> I would think that the equivalent function for ACPI to of_device_probe
> could process these if they are generic and you can associate the
> dependency to a struct device.

Well, something along these lines probably.

> >> Fundamentally, it is a question of probe devices when their
> >> dependencies are present or drivers ensure their dependencies are
> >> ready. IIRC, init systems went thru a similar debate for service
> >> dependencies.
> >
> > The probe ordering is not the entire picture, though.
> >
> > Even if you get the probe ordering right, the problem is going to show up in
> > multiple other places: system suspend/resume, runtime PM, system shutdown,
> > unbinding of drivers.  In all of those cases it is necessary to handle things
> > in a specific order if there is a dependency.
> 
> My understanding was with deferred probe that it also solves suspend
> ordering problems because things are suspended in reverse order of
> probing. I suppose you could have slightly different dependencies for
> suspend, runtime PM, etc. than for probe? Perhaps we need to save the
> list of dependencies as we probe them. I don't think that would be too
> hard to add on to this series, but then if we don't need it now, why
> add it?

As Alan said, there are two problems here.  First off, the ordering of the
list used by system suspend/resume is the registration ordering, not the
probe ordering.  Moreover, though, even if we get the ordering right, it
still is not sufficient for devices with async_suspend set.

To address this, the core will have to make the involved async threads wait
for each other in accordance with the dependencies too.  That, in turn, is
very close to what's needed for runtime PM.

> >> >> In any case, we're talking about adding 1 line.
> >> >
> >> > But also about making the driver core slighly OF-centric.
> >>
> >> How so? The one line is in DT binding parsing code in subsystems, not
> >> driver core. The driver core change is we add every device (that
> >> happened to be created by DT) to the deferred probe list, so they
> >> don't probe right away.
> >
> > The "that happened to be created by DT" part is of concern here.  What is there
> > that makes DT special in that respect?  Why shouldn't that be applicable to
> > devices created by the ACPI core, for example, or by a board file or something
> > else?
> 
> DT is first. I think both examples could use this. Board files avoid
> the problem by controlling the registration order with initcall levels
> and just the call order in the code. You could come up with some way
> to define dependencies for devices in board files and reuse this
> mechanism. ACPI could use this as well if the dependencies are handled
> in a similar way and it seems like they could be.
> 
> >> > Sure, we need OF-specific code and ACPI-specific code wherever different
> >> > handling is required, but doing that at the driver core level seems to be
> >> > a bit of a stretch to me.
> >> >
> >> > Please note that we don't really have ACPI-specific calls in the driver core,
> >> > although we might have added them long ago even before the OF stuff appeared
> >> > in the kernel for the first time.  We didn't do that, (among other things)
> >> > because we didn't want that particular firmware interface to appear special
> >> > in any way and I'm not really sure why it is now OK to make OF look special
> >> > instead.
> >>
> >> I don't think DT is special and we avoid DT specific core changes as
> >> much as possible. I think the difference is DT uses platform_device
> >> and ACPI does not.
> >
> > ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
> > platform devices by default now.
> 
> Okay, I should have grepped for that:
> drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev, NULL);
> drivers/base/platform.c:        len = acpi_device_modalias(dev, buf,
> PAGE_SIZE -1);
> drivers/base/platform.c:        rc = acpi_device_uevent_modalias(dev, env);
> drivers/base/platform.c:        /* Then try ACPI style match */
> drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv))
> 
> These are all cases which have DT version as well, so we're not really
> all that different here. There's a few more for DT, but that probably
> means you have just not hit the problems we have yet. For example,
> what happens if you have an interrupt line in which the controller is
> probed after the device connected to the interrupt line? That required
> resolving irqs in platform_get_irq rather than using static resources
> to support deferred probe.

We don't have this particular problem, because the IRQ controllers are
enumerated in a special way.

> Converting things like this to fwnode calls isn't hard to do. There
> just hasn't been a pressing need or mandate to do so.

Well, to me the problem is actually generic, so it is better to use generic
concepts to start with when trying to address it where that doesn't add too
much overhead.  Otherwise it's very easy to lose the broader context from
one's sight and then to start cutting corners.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 08:35:28 PM Mark Brown wrote:
> 
> --7fVr/IRGAG9sAW4J
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> > On Tue, 20 Oct 2015, Tomeu Vizoso wrote:
> 
> > > This iteration of the series would make this quite easy, as
> > > dependencies are calculated before probes are attempted:
> 
> > > https://lkml.org/lkml/2015/6/17/311
> 
> > But what Rafael is proposing is quite general; it would apply to _all_
> > dependencies as opposed to just those present in DT drivers or those=20
> > affecting platform_devices.
> 
> We'll still need most of the DT bits that are there at the minute (the
> ones strewn around the subsystems) AFAICT since it's at the point where
> we parse the DT and work out what the dependencies are which we probably
> want to do prior to getting the drivers up and will be different for
> ACPI.  I think the level of DT dependency here looks a lot larger than
> it actually is due to the fact that a lot of what's being modified is DT
> parsing code.

Right, something will have to register the dependency, or a "link" between
devices, with the core once we find out that the dependency is there.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 08:35:28 PM Mark Brown wrote:
> 
> --7fVr/IRGAG9sAW4J
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> > On Tue, 20 Oct 2015, Tomeu Vizoso wrote:
> 
> > > This iteration of the series would make this quite easy, as
> > > dependencies are calculated before probes are attempted:
> 
> > > https://lkml.org/lkml/2015/6/17/311
> 
> > But what Rafael is proposing is quite general; it would apply to _all_
> > dependencies as opposed to just those present in DT drivers or those=20
> > affecting platform_devices.
> 
> We'll still need most of the DT bits that are there at the minute (the
> ones strewn around the subsystems) AFAICT since it's at the point where
> we parse the DT and work out what the dependencies are which we probably
> want to do prior to getting the drivers up and will be different for
> ACPI.  I think the level of DT dependency here looks a lot larger than
> it actually is due to the fact that a lot of what's being modified is DT
> parsing code.

Right, something will have to register the dependency, or a "link" between
devices, with the core once we find out that the dependency is there.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 08:35:28 PM Mark Brown wrote:
> 
> --7fVr/IRGAG9sAW4J
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> > On Tue, 20 Oct 2015, Tomeu Vizoso wrote:
> 
> > > This iteration of the series would make this quite easy, as
> > > dependencies are calculated before probes are attempted:
> 
> > > https://lkml.org/lkml/2015/6/17/311
> 
> > But what Rafael is proposing is quite general; it would apply to _all_
> > dependencies as opposed to just those present in DT drivers or those 
> > affecting platform_devices.
> 
> We'll still need most of the DT bits that are there at the minute (the
> ones strewn around the subsystems) AFAICT since it's at the point where
> we parse the DT and work out what the dependencies are which we probably
> want to do prior to getting the drivers up and will be different for
> ACPI.  I think the level of DT dependency here looks a lot larger than
> it actually is due to the fact that a lot of what's being modified is DT
> parsing code.

Right, something will have to register the dependency, or a "link" between
devices, with the core once we find out that the dependency is there.

Thanks,
Rafael

Re: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
>> Hi Russell,
>>
>> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>>>> What you can do is print those devices which have failed to probe at
>>>>> late_initcall() time - possibly augmenting that with reports from
>>>>> subsystems showing what resources are not available, but that's only
>>>>> a guide, because of the "it might or might not be in a kernel module"
>>>>> problem.
>>>>
>>>> Well, adding those reports would give you a changelog similar to the
>>>> one in this series...
>>>
>>> I'm not sure about that, because what I was thinking of is adding
>>> a flag which would be set at late_initcall() time prior to running
>>> a final round of deferred device probing.
>>
>> Which round is the final round?
>> That's the one which didn't manage to bind any new devices to drivers,
>> which is something you only know _after_ the round has been run.
>>
>> So I think we need one extra round to handle this.
>>
>>> This flag would then be used in a deferred_warn() printk function
>>> which would normally be silent, but when this flag is set, it would
>>> print the reason for the deferral - and this would replace (or be
>>> added) to the subsystems and drivers which return -EPROBE_DEFER.
>>>
>>> That has the effect of hiding all the deferrals up until just before
>>> launching into userspace, which should then acomplish two things -
>>> firstly, getting rid of the rather useless deferred messages up to
>>> that point, and secondly printing the reason why the remaining
>>> deferrals are happening.
>>>
>>> That should be a small number of new lines plus a one-line change
>>> in subsystems and drivers.
>>
>> Apart from the extra round we probably can't get rid of, that sounds OK to me.
> 
> Something like this.  I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
> be fwnode?)  See the commented out of_warn_deferred() in
> drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
> for resources should make debugging why things are getting deferred easier.
> 
> We could make driver_deferred_probe_report something that can be
> deactivated again after the last deferred probe run, and provide the
> user with a knob that they can turn it back on again.
> 
> I've tried this out on two of my platforms, including forcing
> driver_deferred_probe_report to be enabled, and I get exactly one
> deferred probe, so not a particularly good test.
> 
> The patch won't apply as-is to mainline for all files; it's based on my
> tree which has some 360 additional patches (which seems to be about
> normal for my tree now.)

I like the concept (I have been thinking along similar lines lately).
But I think this might make the console messages more confusing than
they are now.  The problem is that debug, warn, and error messages
come from a somewhat random set of locations at the moment.  Some
come from the driver probe routines and some come from the subsystems
that the probe routines call.  So the patch is suppressing some
messages, but not others.

One thing that seemed pretty obvious from the patches is that the
current probe routines are somewhat inconsistent in terms of messages,
and that there is room for a set of best practices for messaging.  That
is on my long term wish list, but I'm not sure I'll ever chase after
those windmills.

A couple of specific comments below.


> 
>  drivers/base/dd.c                       | 29 +++++++++++++++++++++++++++++
>  drivers/base/power/domain.c             |  7 +++++--
>  drivers/clk/clkdev.c                    |  9 ++++++++-
>  drivers/gpio/gpiolib-of.c               |  5 +++++
>  drivers/gpu/drm/bridge/dw_hdmi.c        |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
>  drivers/gpu/drm/imx/imx-ldb.c           |  5 +++--
>  drivers/gpu/drm/msm/dsi/dsi.c           |  2 +-
>  drivers/gpu/drm/msm/msm_drv.c           |  3 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
>  drivers/of/irq.c                        |  5 ++++-
>  drivers/pci/host/pci-mvebu.c            |  1 +
>  drivers/pinctrl/core.c                  |  5 +++--
>  drivers/pinctrl/devicetree.c            |  4 ++--
>  drivers/regulator/core.c                |  5 +++--
>  include/linux/device.h                  |  1 +
>  16 files changed, 71 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index be0eb4639128..bb12224f2901 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev)
>  	mutex_unlock(&deferred_probe_mutex);
>  }
>  
> +static bool driver_deferred_probe_report;
> +
> +/**
> + * dev_warn_deferred() - report why a probe has been deferred
> + */
> +void dev_warn_deferred(struct device *dev, const char *fmt, ...)
> +{
> +	if (driver_deferred_probe_report) {
> +		struct va_format vaf;
> +		va_list ap;
> +
> +		va_start(ap, fmt);
> +		vaf.fmt = fmt;
> +		vaf.va = &ap;
> +
> +		dev_warn(dev, "deferring probe: %pV", &vaf);
> +		va_end(ap);
> +	}
> +}
> +EXPORT_SYMBOL_GPL(dev_warn_deferred);

The places where dev_warn_deferred() replaces dev_dbg(), we lose the
ability to turn on debugging and observe the driver reporting the
specific reason the deferral is occurring. So it would be useful to
add an "else dev_dbg()" in dev_warn_deferred() to retain that capability.

> +
>  static bool driver_deferred_probe_enable = false;
> +
>  /**
>   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>   *
> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>  	driver_deferred_probe_trigger();

Couldn't you put the "driver_deferred_probe_report = true" here?  And then
not add another round of probes.


>  	/* Sort as many dependencies as possible before exiting initcalls */
>  	flush_workqueue(deferred_wq);
> +
> +	/* Now one final round, reporting any devices that remain deferred */
> +	driver_deferred_probe_report = true;
> +	driver_deferred_probe_trigger();
> +	/* Sort as many dependencies as possible before exiting initcalls */
> +	flush_workqueue(deferred_wq);
> +
>  	return 0;
>  }

< snip >

-Frank

Re: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
>> Hi Russell,
>>
>> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>>>> What you can do is print those devices which have failed to probe at
>>>>> late_initcall() time - possibly augmenting that with reports from
>>>>> subsystems showing what resources are not available, but that's only
>>>>> a guide, because of the "it might or might not be in a kernel module"
>>>>> problem.
>>>>
>>>> Well, adding those reports would give you a changelog similar to the
>>>> one in this series...
>>>
>>> I'm not sure about that, because what I was thinking of is adding
>>> a flag which would be set at late_initcall() time prior to running
>>> a final round of deferred device probing.
>>
>> Which round is the final round?
>> That's the one which didn't manage to bind any new devices to drivers,
>> which is something you only know _after_ the round has been run.
>>
>> So I think we need one extra round to handle this.
>>
>>> This flag would then be used in a deferred_warn() printk function
>>> which would normally be silent, but when this flag is set, it would
>>> print the reason for the deferral - and this would replace (or be
>>> added) to the subsystems and drivers which return -EPROBE_DEFER.
>>>
>>> That has the effect of hiding all the deferrals up until just before
>>> launching into userspace, which should then acomplish two things -
>>> firstly, getting rid of the rather useless deferred messages up to
>>> that point, and secondly printing the reason why the remaining
>>> deferrals are happening.
>>>
>>> That should be a small number of new lines plus a one-line change
>>> in subsystems and drivers.
>>
>> Apart from the extra round we probably can't get rid of, that sounds OK to me.
> 
> Something like this.  I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
> be fwnode?)  See the commented out of_warn_deferred() in
> drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
> for resources should make debugging why things are getting deferred easier.
> 
> We could make driver_deferred_probe_report something that can be
> deactivated again after the last deferred probe run, and provide the
> user with a knob that they can turn it back on again.
> 
> I've tried this out on two of my platforms, including forcing
> driver_deferred_probe_report to be enabled, and I get exactly one
> deferred probe, so not a particularly good test.
> 
> The patch won't apply as-is to mainline for all files; it's based on my
> tree which has some 360 additional patches (which seems to be about
> normal for my tree now.)

I like the concept (I have been thinking along similar lines lately).
But I think this might make the console messages more confusing than
they are now.  The problem is that debug, warn, and error messages
come from a somewhat random set of locations at the moment.  Some
come from the driver probe routines and some come from the subsystems
that the probe routines call.  So the patch is suppressing some
messages, but not others.

One thing that seemed pretty obvious from the patches is that the
current probe routines are somewhat inconsistent in terms of messages,
and that there is room for a set of best practices for messaging.  That
is on my long term wish list, but I'm not sure I'll ever chase after
those windmills.

A couple of specific comments below.


> 
>  drivers/base/dd.c                       | 29 +++++++++++++++++++++++++++++
>  drivers/base/power/domain.c             |  7 +++++--
>  drivers/clk/clkdev.c                    |  9 ++++++++-
>  drivers/gpio/gpiolib-of.c               |  5 +++++
>  drivers/gpu/drm/bridge/dw_hdmi.c        |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
>  drivers/gpu/drm/imx/imx-ldb.c           |  5 +++--
>  drivers/gpu/drm/msm/dsi/dsi.c           |  2 +-
>  drivers/gpu/drm/msm/msm_drv.c           |  3 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
>  drivers/of/irq.c                        |  5 ++++-
>  drivers/pci/host/pci-mvebu.c            |  1 +
>  drivers/pinctrl/core.c                  |  5 +++--
>  drivers/pinctrl/devicetree.c            |  4 ++--
>  drivers/regulator/core.c                |  5 +++--
>  include/linux/device.h                  |  1 +
>  16 files changed, 71 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index be0eb4639128..bb12224f2901 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev)
>  	mutex_unlock(&deferred_probe_mutex);
>  }
>  
> +static bool driver_deferred_probe_report;
> +
> +/**
> + * dev_warn_deferred() - report why a probe has been deferred
> + */
> +void dev_warn_deferred(struct device *dev, const char *fmt, ...)
> +{
> +	if (driver_deferred_probe_report) {
> +		struct va_format vaf;
> +		va_list ap;
> +
> +		va_start(ap, fmt);
> +		vaf.fmt = fmt;
> +		vaf.va = &ap;
> +
> +		dev_warn(dev, "deferring probe: %pV", &vaf);
> +		va_end(ap);
> +	}
> +}
> +EXPORT_SYMBOL_GPL(dev_warn_deferred);

The places where dev_warn_deferred() replaces dev_dbg(), we lose the
ability to turn on debugging and observe the driver reporting the
specific reason the deferral is occurring. So it would be useful to
add an "else dev_dbg()" in dev_warn_deferred() to retain that capability.

> +
>  static bool driver_deferred_probe_enable = false;
> +
>  /**
>   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>   *
> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>  	driver_deferred_probe_trigger();

Couldn't you put the "driver_deferred_probe_report = true" here?  And then
not add another round of probes.


>  	/* Sort as many dependencies as possible before exiting initcalls */
>  	flush_workqueue(deferred_wq);
> +
> +	/* Now one final round, reporting any devices that remain deferred */
> +	driver_deferred_probe_report = true;
> +	driver_deferred_probe_trigger();
> +	/* Sort as many dependencies as possible before exiting initcalls */
> +	flush_workqueue(deferred_wq);
> +
>  	return 0;
>  }

< snip >

-Frank

Re: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
>> Hi Russell,
>>
>> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>>>> What you can do is print those devices which have failed to probe at
>>>>> late_initcall() time - possibly augmenting that with reports from
>>>>> subsystems showing what resources are not available, but that's only
>>>>> a guide, because of the "it might or might not be in a kernel module"
>>>>> problem.
>>>>
>>>> Well, adding those reports would give you a changelog similar to the
>>>> one in this series...
>>>
>>> I'm not sure about that, because what I was thinking of is adding
>>> a flag which would be set at late_initcall() time prior to running
>>> a final round of deferred device probing.
>>
>> Which round is the final round?
>> That's the one which didn't manage to bind any new devices to drivers,
>> which is something you only know _after_ the round has been run.
>>
>> So I think we need one extra round to handle this.
>>
>>> This flag would then be used in a deferred_warn() printk function
>>> which would normally be silent, but when this flag is set, it would
>>> print the reason for the deferral - and this would replace (or be
>>> added) to the subsystems and drivers which return -EPROBE_DEFER.
>>>
>>> That has the effect of hiding all the deferrals up until just before
>>> launching into userspace, which should then acomplish two things -
>>> firstly, getting rid of the rather useless deferred messages up to
>>> that point, and secondly printing the reason why the remaining
>>> deferrals are happening.
>>>
>>> That should be a small number of new lines plus a one-line change
>>> in subsystems and drivers.
>>
>> Apart from the extra round we probably can't get rid of, that sounds OK to me.
> 
> Something like this.  I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
> be fwnode?)  See the commented out of_warn_deferred() in
> drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
> for resources should make debugging why things are getting deferred easier.
> 
> We could make driver_deferred_probe_report something that can be
> deactivated again after the last deferred probe run, and provide the
> user with a knob that they can turn it back on again.
> 
> I've tried this out on two of my platforms, including forcing
> driver_deferred_probe_report to be enabled, and I get exactly one
> deferred probe, so not a particularly good test.
> 
> The patch won't apply as-is to mainline for all files; it's based on my
> tree which has some 360 additional patches (which seems to be about
> normal for my tree now.)

I like the concept (I have been thinking along similar lines lately).
But I think this might make the console messages more confusing than
they are now.  The problem is that debug, warn, and error messages
come from a somewhat random set of locations at the moment.  Some
come from the driver probe routines and some come from the subsystems
that the probe routines call.  So the patch is suppressing some
messages, but not others.

One thing that seemed pretty obvious from the patches is that the
current probe routines are somewhat inconsistent in terms of messages,
and that there is room for a set of best practices for messaging.  That
is on my long term wish list, but I'm not sure I'll ever chase after
those windmills.

A couple of specific comments below.


> 
>  drivers/base/dd.c                       | 29 +++++++++++++++++++++++++++++
>  drivers/base/power/domain.c             |  7 +++++--
>  drivers/clk/clkdev.c                    |  9 ++++++++-
>  drivers/gpio/gpiolib-of.c               |  5 +++++
>  drivers/gpu/drm/bridge/dw_hdmi.c        |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
>  drivers/gpu/drm/imx/imx-ldb.c           |  5 +++--
>  drivers/gpu/drm/msm/dsi/dsi.c           |  2 +-
>  drivers/gpu/drm/msm/msm_drv.c           |  3 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
>  drivers/of/irq.c                        |  5 ++++-
>  drivers/pci/host/pci-mvebu.c            |  1 +
>  drivers/pinctrl/core.c                  |  5 +++--
>  drivers/pinctrl/devicetree.c            |  4 ++--
>  drivers/regulator/core.c                |  5 +++--
>  include/linux/device.h                  |  1 +
>  16 files changed, 71 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index be0eb4639128..bb12224f2901 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev)
>  	mutex_unlock(&deferred_probe_mutex);
>  }
>  
> +static bool driver_deferred_probe_report;
> +
> +/**
> + * dev_warn_deferred() - report why a probe has been deferred
> + */
> +void dev_warn_deferred(struct device *dev, const char *fmt, ...)
> +{
> +	if (driver_deferred_probe_report) {
> +		struct va_format vaf;
> +		va_list ap;
> +
> +		va_start(ap, fmt);
> +		vaf.fmt = fmt;
> +		vaf.va = &ap;
> +
> +		dev_warn(dev, "deferring probe: %pV", &vaf);
> +		va_end(ap);
> +	}
> +}
> +EXPORT_SYMBOL_GPL(dev_warn_deferred);

The places where dev_warn_deferred() replaces dev_dbg(), we lose the
ability to turn on debugging and observe the driver reporting the
specific reason the deferral is occurring. So it would be useful to
add an "else dev_dbg()" in dev_warn_deferred() to retain that capability.

> +
>  static bool driver_deferred_probe_enable = false;
> +
>  /**
>   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>   *
> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>  	driver_deferred_probe_trigger();

Couldn't you put the "driver_deferred_probe_report = true" here?  And then
not add another round of probes.


>  	/* Sort as many dependencies as possible before exiting initcalls */
>  	flush_workqueue(deferred_wq);
> +
> +	/* Now one final round, reporting any devices that remain deferred */
> +	driver_deferred_probe_report = true;
> +	driver_deferred_probe_trigger();
> +	/* Sort as many dependencies as possible before exiting initcalls */
> +	flush_workqueue(deferred_wq);
> +
>  	return 0;
>  }

< snip >

-Frank

Re: [GIT PULL] On-demand device probing

[Jean-Francois Moine]

Sorry to enter this thread a bit late.

About the number of probe deferred messages, I proposed a simple patch to
reduce them:

	https://lkml.org/lkml/2013/8/20/218

I was wondering how many messages this patch could save...

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [GIT PULL] On-demand device probing

[Jean-Francois Moine]

Sorry to enter this thread a bit late.

About the number of probe deferred messages, I proposed a simple patch to
reduce them:

	https://lkml.org/lkml/2013/8/20/218

I was wondering how many messages this patch could save...

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [GIT PULL] On-demand device probing

[Jean-Francois Moine]

Sorry to enter this thread a bit late.

About the number of probe deferred messages, I proposed a simple patch to
reduce them:

	https://lkml.org/lkml/2013/8/20/218

I was wondering how many messages this patch could save...

--=20
Ken ar c'henta=C3=B1	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [GIT PULL] On-demand device probing

[Jean-Francois Moine]

Sorry to enter this thread a bit late.

About the number of probe deferred messages, I proposed a simple patch to
reduce them:

	https://lkml.org/lkml/2013/8/20/218

I was wondering how many messages this patch could save...

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: Alternative approach to solve the deferred probe

[Russell King - ARM Linux]

On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> > On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> >> Hi Russell,
> >>
> >> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >>>>> What you can do is print those devices which have failed to probe at
> >>>>> late_initcall() time - possibly augmenting that with reports from
> >>>>> subsystems showing what resources are not available, but that's only
> >>>>> a guide, because of the "it might or might not be in a kernel module"
> >>>>> problem.
> >>>>
> >>>> Well, adding those reports would give you a changelog similar to the
> >>>> one in this series...
> >>>
> >>> I'm not sure about that, because what I was thinking of is adding
> >>> a flag which would be set at late_initcall() time prior to running
> >>> a final round of deferred device probing.
> >>
> >> Which round is the final round?
> >> That's the one which didn't manage to bind any new devices to drivers,
> >> which is something you only know _after_ the round has been run.
> >>
> >> So I think we need one extra round to handle this.
> >>
> >>> This flag would then be used in a deferred_warn() printk function
> >>> which would normally be silent, but when this flag is set, it would
> >>> print the reason for the deferral - and this would replace (or be
> >>> added) to the subsystems and drivers which return -EPROBE_DEFER.
> >>>
> >>> That has the effect of hiding all the deferrals up until just before
> >>> launching into userspace, which should then acomplish two things -
> >>> firstly, getting rid of the rather useless deferred messages up to
> >>> that point, and secondly printing the reason why the remaining
> >>> deferrals are happening.
> >>>
> >>> That should be a small number of new lines plus a one-line change
> >>> in subsystems and drivers.
> >>
> >> Apart from the extra round we probably can't get rid of, that sounds OK to me.
> > 
> > Something like this.  I haven't put a lot of effort into it to change all
> > the places which return an -EPROBE_DEFER, and it also looks like we need
> > some helpers to report when we have only an device_node (or should that
> > be fwnode?)  See the commented out of_warn_deferred() in
> > drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
> > for resources should make debugging why things are getting deferred easier.
> > 
> > We could make driver_deferred_probe_report something that can be
> > deactivated again after the last deferred probe run, and provide the
> > user with a knob that they can turn it back on again.
> > 
> > I've tried this out on two of my platforms, including forcing
> > driver_deferred_probe_report to be enabled, and I get exactly one
> > deferred probe, so not a particularly good test.
> > 
> > The patch won't apply as-is to mainline for all files; it's based on my
> > tree which has some 360 additional patches (which seems to be about
> > normal for my tree now.)
> 
> I like the concept (I have been thinking along similar lines lately).
> But I think this might make the console messages more confusing than
> they are now.

If messages end up being given from the subsystem rather than the driver,
surely they become more consistent?

> The problem is that debug, warn, and error messages
> come from a somewhat random set of locations at the moment.  Some
> come from the driver probe routines and some come from the subsystems
> that the probe routines call.  So the patch is suppressing some
> messages, but not others.

The patch is not complete (read the description above).

> > +void dev_warn_deferred(struct device *dev, const char *fmt, ...)
> > +{
> > +	if (driver_deferred_probe_report) {
> > +		struct va_format vaf;
> > +		va_list ap;
> > +
> > +		va_start(ap, fmt);
> > +		vaf.fmt = fmt;
> > +		vaf.va = &ap;
> > +
> > +		dev_warn(dev, "deferring probe: %pV", &vaf);
> > +		va_end(ap);
> > +	}
> > +}
> > +EXPORT_SYMBOL_GPL(dev_warn_deferred);
> 
> The places where dev_warn_deferred() replaces dev_dbg(), we lose the
> ability to turn on debugging and observe the driver reporting the
> specific reason the deferral is occurring. So it would be useful to
> add an "else dev_dbg()" in dev_warn_deferred() to retain that capability.

That's a possibility.

> 
> > +
> >  static bool driver_deferred_probe_enable = false;
> > +
> >  /**
> >   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
> >   *
> > @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
> >  	driver_deferred_probe_trigger();
> 
> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
> not add another round of probes.

The idea is not to report anything for drivers that were deferred
during the normal bootup.  The above is part of the normal bootup,
and the deferred activity should not be warned about.

If we have any devices still deferring after _this_ round, that must
indicate that some resource they want is not available, and that
should be warned about.

Of course, modules can defer too - and I made some suggestions in my
waffle above the patch about that.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Alternative approach to solve the deferred probe

[Russell King - ARM Linux]

On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> > On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> >> Hi Russell,
> >>
> >> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >>>>> What you can do is print those devices which have failed to probe at
> >>>>> late_initcall() time - possibly augmenting that with reports from
> >>>>> subsystems showing what resources are not available, but that's only
> >>>>> a guide, because of the "it might or might not be in a kernel module"
> >>>>> problem.
> >>>>
> >>>> Well, adding those reports would give you a changelog similar to the
> >>>> one in this series...
> >>>
> >>> I'm not sure about that, because what I was thinking of is adding
> >>> a flag which would be set at late_initcall() time prior to running
> >>> a final round of deferred device probing.
> >>
> >> Which round is the final round?
> >> That's the one which didn't manage to bind any new devices to drivers,
> >> which is something you only know _after_ the round has been run.
> >>
> >> So I think we need one extra round to handle this.
> >>
> >>> This flag would then be used in a deferred_warn() printk function
> >>> which would normally be silent, but when this flag is set, it would
> >>> print the reason for the deferral - and this would replace (or be
> >>> added) to the subsystems and drivers which return -EPROBE_DEFER.
> >>>
> >>> That has the effect of hiding all the deferrals up until just before
> >>> launching into userspace, which should then acomplish two things -
> >>> firstly, getting rid of the rather useless deferred messages up to
> >>> that point, and secondly printing the reason why the remaining
> >>> deferrals are happening.
> >>>
> >>> That should be a small number of new lines plus a one-line change
> >>> in subsystems and drivers.
> >>
> >> Apart from the extra round we probably can't get rid of, that sounds OK to me.
> > 
> > Something like this.  I haven't put a lot of effort into it to change all
> > the places which return an -EPROBE_DEFER, and it also looks like we need
> > some helpers to report when we have only an device_node (or should that
> > be fwnode?)  See the commented out of_warn_deferred() in
> > drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
> > for resources should make debugging why things are getting deferred easier.
> > 
> > We could make driver_deferred_probe_report something that can be
> > deactivated again after the last deferred probe run, and provide the
> > user with a knob that they can turn it back on again.
> > 
> > I've tried this out on two of my platforms, including forcing
> > driver_deferred_probe_report to be enabled, and I get exactly one
> > deferred probe, so not a particularly good test.
> > 
> > The patch won't apply as-is to mainline for all files; it's based on my
> > tree which has some 360 additional patches (which seems to be about
> > normal for my tree now.)
> 
> I like the concept (I have been thinking along similar lines lately).
> But I think this might make the console messages more confusing than
> they are now.

If messages end up being given from the subsystem rather than the driver,
surely they become more consistent?

> The problem is that debug, warn, and error messages
> come from a somewhat random set of locations at the moment.  Some
> come from the driver probe routines and some come from the subsystems
> that the probe routines call.  So the patch is suppressing some
> messages, but not others.

The patch is not complete (read the description above).

> > +void dev_warn_deferred(struct device *dev, const char *fmt, ...)
> > +{
> > +	if (driver_deferred_probe_report) {
> > +		struct va_format vaf;
> > +		va_list ap;
> > +
> > +		va_start(ap, fmt);
> > +		vaf.fmt = fmt;
> > +		vaf.va = &ap;
> > +
> > +		dev_warn(dev, "deferring probe: %pV", &vaf);
> > +		va_end(ap);
> > +	}
> > +}
> > +EXPORT_SYMBOL_GPL(dev_warn_deferred);
> 
> The places where dev_warn_deferred() replaces dev_dbg(), we lose the
> ability to turn on debugging and observe the driver reporting the
> specific reason the deferral is occurring. So it would be useful to
> add an "else dev_dbg()" in dev_warn_deferred() to retain that capability.

That's a possibility.

> 
> > +
> >  static bool driver_deferred_probe_enable = false;
> > +
> >  /**
> >   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
> >   *
> > @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
> >  	driver_deferred_probe_trigger();
> 
> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
> not add another round of probes.

The idea is not to report anything for drivers that were deferred
during the normal bootup.  The above is part of the normal bootup,
and the deferred activity should not be warned about.

If we have any devices still deferring after _this_ round, that must
indicate that some resource they want is not available, and that
should be warned about.

Of course, modules can defer too - and I made some suggestions in my
waffle above the patch about that.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Alternative approach to solve the deferred probe

[Russell King - ARM Linux]

On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> > On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> >> Hi Russell,
> >>
> >> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >>>>> What you can do is print those devices which have failed to probe at
> >>>>> late_initcall() time - possibly augmenting that with reports from
> >>>>> subsystems showing what resources are not available, but that's only
> >>>>> a guide, because of the "it might or might not be in a kernel module"
> >>>>> problem.
> >>>>
> >>>> Well, adding those reports would give you a changelog similar to the
> >>>> one in this series...
> >>>
> >>> I'm not sure about that, because what I was thinking of is adding
> >>> a flag which would be set at late_initcall() time prior to running
> >>> a final round of deferred device probing.
> >>
> >> Which round is the final round?
> >> That's the one which didn't manage to bind any new devices to drivers,
> >> which is something you only know _after_ the round has been run.
> >>
> >> So I think we need one extra round to handle this.
> >>
> >>> This flag would then be used in a deferred_warn() printk function
> >>> which would normally be silent, but when this flag is set, it would
> >>> print the reason for the deferral - and this would replace (or be
> >>> added) to the subsystems and drivers which return -EPROBE_DEFER.
> >>>
> >>> That has the effect of hiding all the deferrals up until just before
> >>> launching into userspace, which should then acomplish two things -
> >>> firstly, getting rid of the rather useless deferred messages up to
> >>> that point, and secondly printing the reason why the remaining
> >>> deferrals are happening.
> >>>
> >>> That should be a small number of new lines plus a one-line change
> >>> in subsystems and drivers.
> >>
> >> Apart from the extra round we probably can't get rid of, that sounds OK to me.
> > 
> > Something like this.  I haven't put a lot of effort into it to change all
> > the places which return an -EPROBE_DEFER, and it also looks like we need
> > some helpers to report when we have only an device_node (or should that
> > be fwnode?)  See the commented out of_warn_deferred() in
> > drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
> > for resources should make debugging why things are getting deferred easier.
> > 
> > We could make driver_deferred_probe_report something that can be
> > deactivated again after the last deferred probe run, and provide the
> > user with a knob that they can turn it back on again.
> > 
> > I've tried this out on two of my platforms, including forcing
> > driver_deferred_probe_report to be enabled, and I get exactly one
> > deferred probe, so not a particularly good test.
> > 
> > The patch won't apply as-is to mainline for all files; it's based on my
> > tree which has some 360 additional patches (which seems to be about
> > normal for my tree now.)
> 
> I like the concept (I have been thinking along similar lines lately).
> But I think this might make the console messages more confusing than
> they are now.

If messages end up being given from the subsystem rather than the driver,
surely they become more consistent?

> The problem is that debug, warn, and error messages
> come from a somewhat random set of locations at the moment.  Some
> come from the driver probe routines and some come from the subsystems
> that the probe routines call.  So the patch is suppressing some
> messages, but not others.

The patch is not complete (read the description above).

> > +void dev_warn_deferred(struct device *dev, const char *fmt, ...)
> > +{
> > +	if (driver_deferred_probe_report) {
> > +		struct va_format vaf;
> > +		va_list ap;
> > +
> > +		va_start(ap, fmt);
> > +		vaf.fmt = fmt;
> > +		vaf.va = &ap;
> > +
> > +		dev_warn(dev, "deferring probe: %pV", &vaf);
> > +		va_end(ap);
> > +	}
> > +}
> > +EXPORT_SYMBOL_GPL(dev_warn_deferred);
> 
> The places where dev_warn_deferred() replaces dev_dbg(), we lose the
> ability to turn on debugging and observe the driver reporting the
> specific reason the deferral is occurring. So it would be useful to
> add an "else dev_dbg()" in dev_warn_deferred() to retain that capability.

That's a possibility.

> 
> > +
> >  static bool driver_deferred_probe_enable = false;
> > +
> >  /**
> >   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
> >   *
> > @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
> >  	driver_deferred_probe_trigger();
> 
> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
> not add another round of probes.

The idea is not to report anything for drivers that were deferred
during the normal bootup.  The above is part of the normal bootup,
and the deferred activity should not be warned about.

If we have any devices still deferring after _this_ round, that must
indicate that some resource they want is not available, and that
should be warned about.

Of course, modules can defer too - and I made some suggestions in my
waffle above the patch about that.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Geert Uytterhoeven]

Hi Rafael,

On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
>> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
>> > platform devices by default now.
>>
>> Okay, I should have grepped for that:
>> drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev, NULL);
>> drivers/base/platform.c:        len = acpi_device_modalias(dev, buf,
>> PAGE_SIZE -1);
>> drivers/base/platform.c:        rc = acpi_device_uevent_modalias(dev, env);
>> drivers/base/platform.c:        /* Then try ACPI style match */
>> drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv))
>>
>> These are all cases which have DT version as well, so we're not really
>> all that different here. There's a few more for DT, but that probably
>> means you have just not hit the problems we have yet. For example,
>> what happens if you have an interrupt line in which the controller is
>> probed after the device connected to the interrupt line? That required
>> resolving irqs in platform_get_irq rather than using static resources
>> to support deferred probe.
>
> We don't have this particular problem, because the IRQ controllers are
> enumerated in a special way.

What does "in a special way" mean? Can you please be more specific?

Can you have interrupt controllers that depend on clocks, pin controllers,
and PM domains?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] On-demand device probing

[Geert Uytterhoeven]

Hi Rafael,

On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
>> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
>> > platform devices by default now.
>>
>> Okay, I should have grepped for that:
>> drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev, NULL);
>> drivers/base/platform.c:        len = acpi_device_modalias(dev, buf,
>> PAGE_SIZE -1);
>> drivers/base/platform.c:        rc = acpi_device_uevent_modalias(dev, env);
>> drivers/base/platform.c:        /* Then try ACPI style match */
>> drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv))
>>
>> These are all cases which have DT version as well, so we're not really
>> all that different here. There's a few more for DT, but that probably
>> means you have just not hit the problems we have yet. For example,
>> what happens if you have an interrupt line in which the controller is
>> probed after the device connected to the interrupt line? That required
>> resolving irqs in platform_get_irq rather than using static resources
>> to support deferred probe.
>
> We don't have this particular problem, because the IRQ controllers are
> enumerated in a special way.

What does "in a special way" mean? Can you please be more specific?

Can you have interrupt controllers that depend on clocks, pin controllers,
and PM domains?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] On-demand device probing

[Geert Uytterhoeven]

Hi Rafael,

On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
>> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
>> > platform devices by default now.
>>
>> Okay, I should have grepped for that:
>> drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev, NULL);
>> drivers/base/platform.c:        len = acpi_device_modalias(dev, buf,
>> PAGE_SIZE -1);
>> drivers/base/platform.c:        rc = acpi_device_uevent_modalias(dev, env);
>> drivers/base/platform.c:        /* Then try ACPI style match */
>> drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv))
>>
>> These are all cases which have DT version as well, so we're not really
>> all that different here. There's a few more for DT, but that probably
>> means you have just not hit the problems we have yet. For example,
>> what happens if you have an interrupt line in which the controller is
>> probed after the device connected to the interrupt line? That required
>> resolving irqs in platform_get_irq rather than using static resources
>> to support deferred probe.
>
> We don't have this particular problem, because the IRQ controllers are
> enumerated in a special way.

What does "in a special way" mean? Can you please be more specific?

Can you have interrupt controllers that depend on clocks, pin controllers,
and PM domains?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:

< snip >

>>> +
>>>  static bool driver_deferred_probe_enable = false;
>>> +
>>>  /**
>>>   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>   *
>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>  	driver_deferred_probe_trigger();
>>
>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>> not add another round of probes.
> 
> The idea is not to report anything for drivers that were deferred
> during the normal bootup.  The above is part of the normal bootup,
> and the deferred activity should not be warned about.

The above is currently the last point for probe to succeed or defer
(until possibly, as you mentioned, module loading resolves the defer).
If a probe defers above, it will defer again below.  The set of defers
should be exactly the same above and below.

> 
> If we have any devices still deferring after _this_ round, that must
> indicate that some resource they want is not available, and that
> should be warned about.
> 
> Of course, modules can defer too - and I made some suggestions in my
> waffle above the patch about that.
> 

< adding back trimmed, for fuller context >

>>>  	/* Sort as many dependencies as possible before exiting initcalls */
>>>  	flush_workqueue(deferred_wq);
>>> +
>>> +	/* Now one final round, reporting any devices that remain deferred */
>>> +	driver_deferred_probe_report = true;
>>> +	driver_deferred_probe_trigger();
>>> +	/* Sort as many dependencies as possible before exiting initcalls */
>>> +	flush_workqueue(deferred_wq);
>>> +
>>>  	return 0;
>>>  }

Re: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:

< snip >

>>> +
>>>  static bool driver_deferred_probe_enable = false;
>>> +
>>>  /**
>>>   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>   *
>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>  	driver_deferred_probe_trigger();
>>
>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>> not add another round of probes.
> 
> The idea is not to report anything for drivers that were deferred
> during the normal bootup.  The above is part of the normal bootup,
> and the deferred activity should not be warned about.

The above is currently the last point for probe to succeed or defer
(until possibly, as you mentioned, module loading resolves the defer).
If a probe defers above, it will defer again below.  The set of defers
should be exactly the same above and below.

> 
> If we have any devices still deferring after _this_ round, that must
> indicate that some resource they want is not available, and that
> should be warned about.
> 
> Of course, modules can defer too - and I made some suggestions in my
> waffle above the patch about that.
> 

< adding back trimmed, for fuller context >

>>>  	/* Sort as many dependencies as possible before exiting initcalls */
>>>  	flush_workqueue(deferred_wq);
>>> +
>>> +	/* Now one final round, reporting any devices that remain deferred */
>>> +	driver_deferred_probe_report = true;
>>> +	driver_deferred_probe_trigger();
>>> +	/* Sort as many dependencies as possible before exiting initcalls */
>>> +	flush_workqueue(deferred_wq);
>>> +
>>>  	return 0;
>>>  }

Re: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:

< snip >

>>> +
>>>  static bool driver_deferred_probe_enable = false;
>>> +
>>>  /**
>>>   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>   *
>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>  	driver_deferred_probe_trigger();
>>
>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>> not add another round of probes.
> 
> The idea is not to report anything for drivers that were deferred
> during the normal bootup.  The above is part of the normal bootup,
> and the deferred activity should not be warned about.

The above is currently the last point for probe to succeed or defer
(until possibly, as you mentioned, module loading resolves the defer).
If a probe defers above, it will defer again below.  The set of defers
should be exactly the same above and below.

> 
> If we have any devices still deferring after _this_ round, that must
> indicate that some resource they want is not available, and that
> should be warned about.
> 
> Of course, modules can defer too - and I made some suggestions in my
> waffle above the patch about that.
> 

< adding back trimmed, for fuller context >

>>>  	/* Sort as many dependencies as possible before exiting initcalls */
>>>  	flush_workqueue(deferred_wq);
>>> +
>>> +	/* Now one final round, reporting any devices that remain deferred */
>>> +	driver_deferred_probe_report = true;
>>> +	driver_deferred_probe_trigger();
>>> +	/* Sort as many dependencies as possible before exiting initcalls */
>>> +	flush_workqueue(deferred_wq);
>>> +
>>>  	return 0;
>>>  }

Re: [GIT PULL] On-demand device probing

[Frank Rowand]

On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> On 18 October 2015 at 21:53, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>>>> On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:

< snip >

> hope you don't mind I summarize the points taken instead of replying
> to the individual emails. I tried to address all the concerns that
> have been raised again in the cover letter, but I guess I did a bad
> job at explaining myself, so here's another (more in-depth) go at it.

< snip >

> 3) Regarding total boot time, I don't expect this series to make much
> of a difference because though we would save a lot of matching and
> querying for resources, that's little time compared with how long we
> wait for hardware to react during probing. Async probing is more
> likely to help with drivers that take a long time to probe.

And then in your reply to Russell's reply to your email you say:

> To be clear, I was saying that this series should NOT affect total
> boot times much.

I'm confused.  If I understood correctly, improving boot time was
the key justification for accepting this patch set.  For example,
from "[PATCH v7 0/20] On-demand device probing":

   I have a problem with the panel on my Tegra Chromebook taking longer
   than expected to be ready during boot (Stéphane Marchesin reported what
   is basically the same issue in [0]), and have looked into ordered
   probing as a better way of solving this than moving nodes around in the
   DT or playing with initcall levels and linking order.

   ...

   With this series I get the kernel to output to the panel in 0.5s,
   instead of 2.8s.

Alexander Holler reported improved boot times for his patch set
in August, which is another approach to ordering probes
(http://article.gmane.org/gmane.linux.drivers.devicetree/133010).
His results for 5 boards was four booted faster, one slightly
slower:

   Some numbers (5 boots on each board, without and with ordering drivers),
   all times are seconds.

   Kirkwood (dockstar, armv5):

   Boot to "Freeing unused kernel memory" (includes mounting the rootfs),
   unordered:
   4.456016 3.937801 4.114788 4.114526 3.949480 (average 4.1145222)
   ordered:
   3.173054 3.164045 3.141418 3.480679 3.459298 (3.2836988)
   Time needed to sort (of_init_build_order()):
   0.003024
   Time needed to match drivers to the order (without calling them):
   0.002884

   Beagleboard (rev C4, armv7):

   unordered:
   6.706024 6.821746 6.696014 6.673675 6.769866 (6.733465)
   ordered:
   5.544860 5.514160 5.505859 5.527374 5.496795 (5.5178096)
   sorting: 0.021209
   matching: 0.006165

   Beaglebone Black (rev A5, armv7):

   unordered:
   3.826531 3.825662 3.826648 3.825434 3.825263 (3.8259076)
   ordered:
   2.838554 2.838322 2.839459 2.838467 2.838421 (2.8386446)
   sorting: 0.004769
   matching: 0.004860

   imx6q (armv7):

   unordered:
   3.451998 3.418864 3.446952 3.429974 3.440996 (3.4377568)
   ordered:
   3.538312 3.549019 3.538105 3.515916 3.555715 (3.5394134)
   sorting: 0.004622
   matching: 0.003868

While not as dramatic as your results, they are somewhat supportive.
What has changed your assessment that the on-demand device probing
patches will give a big boot performance increase?  Do you have
new data or analysis?

-Frank

Re: [GIT PULL] On-demand device probing

[Frank Rowand]

On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> On 18 October 2015 at 21:53, Mark Brown <broonie@kernel.org> wrote:
>> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>>>> On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:

< snip >

> hope you don't mind I summarize the points taken instead of replying
> to the individual emails. I tried to address all the concerns that
> have been raised again in the cover letter, but I guess I did a bad
> job at explaining myself, so here's another (more in-depth) go at it.

< snip >

> 3) Regarding total boot time, I don't expect this series to make much
> of a difference because though we would save a lot of matching and
> querying for resources, that's little time compared with how long we
> wait for hardware to react during probing. Async probing is more
> likely to help with drivers that take a long time to probe.

And then in your reply to Russell's reply to your email you say:

> To be clear, I was saying that this series should NOT affect total
> boot times much.

I'm confused.  If I understood correctly, improving boot time was
the key justification for accepting this patch set.  For example,
from "[PATCH v7 0/20] On-demand device probing":

   I have a problem with the panel on my Tegra Chromebook taking longer
   than expected to be ready during boot (Stéphane Marchesin reported what
   is basically the same issue in [0]), and have looked into ordered
   probing as a better way of solving this than moving nodes around in the
   DT or playing with initcall levels and linking order.

   ...

   With this series I get the kernel to output to the panel in 0.5s,
   instead of 2.8s.

Alexander Holler reported improved boot times for his patch set
in August, which is another approach to ordering probes
(http://article.gmane.org/gmane.linux.drivers.devicetree/133010).
His results for 5 boards was four booted faster, one slightly
slower:

   Some numbers (5 boots on each board, without and with ordering drivers),
   all times are seconds.

   Kirkwood (dockstar, armv5):

   Boot to "Freeing unused kernel memory" (includes mounting the rootfs),
   unordered:
   4.456016 3.937801 4.114788 4.114526 3.949480 (average 4.1145222)
   ordered:
   3.173054 3.164045 3.141418 3.480679 3.459298 (3.2836988)
   Time needed to sort (of_init_build_order()):
   0.003024
   Time needed to match drivers to the order (without calling them):
   0.002884

   Beagleboard (rev C4, armv7):

   unordered:
   6.706024 6.821746 6.696014 6.673675 6.769866 (6.733465)
   ordered:
   5.544860 5.514160 5.505859 5.527374 5.496795 (5.5178096)
   sorting: 0.021209
   matching: 0.006165

   Beaglebone Black (rev A5, armv7):

   unordered:
   3.826531 3.825662 3.826648 3.825434 3.825263 (3.8259076)
   ordered:
   2.838554 2.838322 2.839459 2.838467 2.838421 (2.8386446)
   sorting: 0.004769
   matching: 0.004860

   imx6q (armv7):

   unordered:
   3.451998 3.418864 3.446952 3.429974 3.440996 (3.4377568)
   ordered:
   3.538312 3.549019 3.538105 3.515916 3.555715 (3.5394134)
   sorting: 0.004622
   matching: 0.003868

While not as dramatic as your results, they are somewhat supportive.
What has changed your assessment that the on-demand device probing
patches will give a big boot performance increase?  Do you have
new data or analysis?

-Frank

Re: [GIT PULL] On-demand device probing

[Frank Rowand]

On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> On 18 October 2015 at 21:53, Mark Brown <broonie@kernel.org> wrote:
>> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
>>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
>>>> On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:

< snip >

> hope you don't mind I summarize the points taken instead of replying
> to the individual emails. I tried to address all the concerns that
> have been raised again in the cover letter, but I guess I did a bad
> job at explaining myself, so here's another (more in-depth) go at it.

< snip >

> 3) Regarding total boot time, I don't expect this series to make much
> of a difference because though we would save a lot of matching and
> querying for resources, that's little time compared with how long we
> wait for hardware to react during probing. Async probing is more
> likely to help with drivers that take a long time to probe.

And then in your reply to Russell's reply to your email you say:

> To be clear, I was saying that this series should NOT affect total
> boot times much.

I'm confused.  If I understood correctly, improving boot time was
the key justification for accepting this patch set.  For example,
from "[PATCH v7 0/20] On-demand device probing":

   I have a problem with the panel on my Tegra Chromebook taking longer
   than expected to be ready during boot (Stéphane Marchesin reported what
   is basically the same issue in [0]), and have looked into ordered
   probing as a better way of solving this than moving nodes around in the
   DT or playing with initcall levels and linking order.

   ...

   With this series I get the kernel to output to the panel in 0.5s,
   instead of 2.8s.

Alexander Holler reported improved boot times for his patch set
in August, which is another approach to ordering probes
(http://article.gmane.org/gmane.linux.drivers.devicetree/133010).
His results for 5 boards was four booted faster, one slightly
slower:

   Some numbers (5 boots on each board, without and with ordering drivers),
   all times are seconds.

   Kirkwood (dockstar, armv5):

   Boot to "Freeing unused kernel memory" (includes mounting the rootfs),
   unordered:
   4.456016 3.937801 4.114788 4.114526 3.949480 (average 4.1145222)
   ordered:
   3.173054 3.164045 3.141418 3.480679 3.459298 (3.2836988)
   Time needed to sort (of_init_build_order()):
   0.003024
   Time needed to match drivers to the order (without calling them):
   0.002884

   Beagleboard (rev C4, armv7):

   unordered:
   6.706024 6.821746 6.696014 6.673675 6.769866 (6.733465)
   ordered:
   5.544860 5.514160 5.505859 5.527374 5.496795 (5.5178096)
   sorting: 0.021209
   matching: 0.006165

   Beaglebone Black (rev A5, armv7):

   unordered:
   3.826531 3.825662 3.826648 3.825434 3.825263 (3.8259076)
   ordered:
   2.838554 2.838322 2.839459 2.838467 2.838421 (2.8386446)
   sorting: 0.004769
   matching: 0.004860

   imx6q (armv7):

   unordered:
   3.451998 3.418864 3.446952 3.429974 3.440996 (3.4377568)
   ordered:
   3.538312 3.549019 3.538105 3.515916 3.555715 (3.5394134)
   sorting: 0.004622
   matching: 0.003868

While not as dramatic as your results, they are somewhat supportive.
What has changed your assessment that the on-demand device probing
patches will give a big boot performance increase?  Do you have
new data or analysis?

-Frank

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:

> > To be clear, I was saying that this series should NOT affect total
> > boot times much.

> I'm confused.  If I understood correctly, improving boot time was
> the key justification for accepting this patch set.  For example,
> from "[PATCH v7 0/20] On-demand device probing":
> 
>    I have a problem with the panel on my Tegra Chromebook taking longer
>    than expected to be ready during boot (Stéphane Marchesin reported what
>    is basically the same issue in [0]), and have looked into ordered
>    probing as a better way of solving this than moving nodes around in the
>    DT or playing with initcall levels and linking order.
> 
>    ...
> 
>    With this series I get the kernel to output to the panel in 0.5s,
>    instead of 2.8s.

Overall boot time and time to get some individual built in component up
and running aren't the same thing - what this'll do is get things up
more in the link order of the leaf consumers rather than deferring those
leaf consumers when their dependencies aren't ready yet.

> While not as dramatic as your results, they are somewhat supportive.
> What has changed your assessment that the on-demand device probing
> patches will give a big boot performance increase?  Do you have
> new data or analysis?

See above, my understanding was that the performance improvements were
more around improved control/predictability/handwave of the boot
ordering rather than total time.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:

> > To be clear, I was saying that this series should NOT affect total
> > boot times much.

> I'm confused.  If I understood correctly, improving boot time was
> the key justification for accepting this patch set.  For example,
> from "[PATCH v7 0/20] On-demand device probing":
> 
>    I have a problem with the panel on my Tegra Chromebook taking longer
>    than expected to be ready during boot (Stéphane Marchesin reported what
>    is basically the same issue in [0]), and have looked into ordered
>    probing as a better way of solving this than moving nodes around in the
>    DT or playing with initcall levels and linking order.
> 
>    ...
> 
>    With this series I get the kernel to output to the panel in 0.5s,
>    instead of 2.8s.

Overall boot time and time to get some individual built in component up
and running aren't the same thing - what this'll do is get things up
more in the link order of the leaf consumers rather than deferring those
leaf consumers when their dependencies aren't ready yet.

> While not as dramatic as your results, they are somewhat supportive.
> What has changed your assessment that the on-demand device probing
> patches will give a big boot performance increase?  Do you have
> new data or analysis?

See above, my understanding was that the performance improvements were
more around improved control/predictability/handwave of the boot
ordering rather than total time.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:

> > To be clear, I was saying that this series should NOT affect total
> > boot times much.

> I'm confused.  If I understood correctly, improving boot time was
> the key justification for accepting this patch set.  For example,
> from "[PATCH v7 0/20] On-demand device probing":
> 
>    I have a problem with the panel on my Tegra Chromebook taking longer
>    than expected to be ready during boot (Stéphane Marchesin reported what
>    is basically the same issue in [0]), and have looked into ordered
>    probing as a better way of solving this than moving nodes around in the
>    DT or playing with initcall levels and linking order.
> 
>    ...
> 
>    With this series I get the kernel to output to the panel in 0.5s,
>    instead of 2.8s.

Overall boot time and time to get some individual built in component up
and running aren't the same thing - what this'll do is get things up
more in the link order of the leaf consumers rather than deferring those
leaf consumers when their dependencies aren't ready yet.

> While not as dramatic as your results, they are somewhat supportive.
> What has changed your assessment that the on-demand device probing
> patches will give a big boot performance increase?  Do you have
> new data or analysis?

See above, my understanding was that the performance improvements were
more around improved control/predictability/handwave of the boot
ordering rather than total time.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Alternative approach to solve the deferred probe

[Grygorii Strashko]

On 10/21/2015 06:36 PM, Frank Rowand wrote:
> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> 
> < snip >
> 
>>>> +
>>>>   static bool driver_deferred_probe_enable = false;
>>>> +
>>>>   /**
>>>>    * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>    *
>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>   	driver_deferred_probe_trigger();
>>>
>>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>>> not add another round of probes.
>>
>> The idea is not to report anything for drivers that were deferred
>> during the normal bootup.  The above is part of the normal bootup,
>> and the deferred activity should not be warned about.
> 
> The above is currently the last point for probe to succeed or defer
> (until possibly, as you mentioned, module loading resolves the defer).
> If a probe defers above, it will defer again below.  The set of defers
> should be exactly the same above and below.
> 

Unfortunately this is not "the last point for probe to succeed or defer".
There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
(like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
Yes - they probably need to be updated to use module_init(), but that's what
we have now). Those drivers will re-trigger deferred device probing if their
probe succeeded.

As result, it is impossible to say when will it happen the 
"final round of deferred device probing" :( and final list of drivers which
was "deferred forever" will be know only when kernel exits to User space 
("deferred forever" - before loading modules).

May be, we also can consider adding debug_fs entry which can be used to display
actual state of deferred_probe_pending_list? 

>>
>> If we have any devices still deferring after _this_ round, that must
>> indicate that some resource they want is not available, and that
>> should be warned about.
>>
>> Of course, modules can defer too - and I made some suggestions in my
>> waffle above the patch about that.
>>
> 
> < adding back trimmed, for fuller context >
> 
>>>>   	/* Sort as many dependencies as possible before exiting initcalls */
>>>>   	flush_workqueue(deferred_wq);
>>>> +
>>>> +	/* Now one final round, reporting any devices that remain deferred */
>>>> +	driver_deferred_probe_report = true;
>>>> +	driver_deferred_probe_trigger();
>>>> +	/* Sort as many dependencies as possible before exiting initcalls */
>>>> +	flush_workqueue(deferred_wq);
>>>> +
>>>>   	return 0;
>>>>   }


-- 
regards,
-grygorii

Re: Alternative approach to solve the deferred probe

[Grygorii Strashko]

On 10/21/2015 06:36 PM, Frank Rowand wrote:
> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> 
> < snip >
> 
>>>> +
>>>>   static bool driver_deferred_probe_enable = false;
>>>> +
>>>>   /**
>>>>    * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>    *
>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>   	driver_deferred_probe_trigger();
>>>
>>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>>> not add another round of probes.
>>
>> The idea is not to report anything for drivers that were deferred
>> during the normal bootup.  The above is part of the normal bootup,
>> and the deferred activity should not be warned about.
> 
> The above is currently the last point for probe to succeed or defer
> (until possibly, as you mentioned, module loading resolves the defer).
> If a probe defers above, it will defer again below.  The set of defers
> should be exactly the same above and below.
> 

Unfortunately this is not "the last point for probe to succeed or defer".
There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
(like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
Yes - they probably need to be updated to use module_init(), but that's what
we have now). Those drivers will re-trigger deferred device probing if their
probe succeeded.

As result, it is impossible to say when will it happen the 
"final round of deferred device probing" :( and final list of drivers which
was "deferred forever" will be know only when kernel exits to User space 
("deferred forever" - before loading modules).

May be, we also can consider adding debug_fs entry which can be used to display
actual state of deferred_probe_pending_list? 

>>
>> If we have any devices still deferring after _this_ round, that must
>> indicate that some resource they want is not available, and that
>> should be warned about.
>>
>> Of course, modules can defer too - and I made some suggestions in my
>> waffle above the patch about that.
>>
> 
> < adding back trimmed, for fuller context >
> 
>>>>   	/* Sort as many dependencies as possible before exiting initcalls */
>>>>   	flush_workqueue(deferred_wq);
>>>> +
>>>> +	/* Now one final round, reporting any devices that remain deferred */
>>>> +	driver_deferred_probe_report = true;
>>>> +	driver_deferred_probe_trigger();
>>>> +	/* Sort as many dependencies as possible before exiting initcalls */
>>>> +	flush_workqueue(deferred_wq);
>>>> +
>>>>   	return 0;
>>>>   }


-- 
regards,
-grygorii

Re: Alternative approach to solve the deferred probe

[Grygorii Strashko]

On 10/21/2015 06:36 PM, Frank Rowand wrote:
> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> 
> < snip >
> 
>>>> +
>>>>   static bool driver_deferred_probe_enable = false;
>>>> +
>>>>   /**
>>>>    * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>    *
>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>   	driver_deferred_probe_trigger();
>>>
>>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>>> not add another round of probes.
>>
>> The idea is not to report anything for drivers that were deferred
>> during the normal bootup.  The above is part of the normal bootup,
>> and the deferred activity should not be warned about.
> 
> The above is currently the last point for probe to succeed or defer
> (until possibly, as you mentioned, module loading resolves the defer).
> If a probe defers above, it will defer again below.  The set of defers
> should be exactly the same above and below.
> 

Unfortunately this is not "the last point for probe to succeed or defer".
There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
(like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
Yes - they probably need to be updated to use module_init(), but that's what
we have now). Those drivers will re-trigger deferred device probing if their
probe succeeded.

As result, it is impossible to say when will it happen the 
"final round of deferred device probing" :( and final list of drivers which
was "deferred forever" will be know only when kernel exits to User space 
("deferred forever" - before loading modules).

May be, we also can consider adding debug_fs entry which can be used to display
actual state of deferred_probe_pending_list? 

>>
>> If we have any devices still deferring after _this_ round, that must
>> indicate that some resource they want is not available, and that
>> should be warned about.
>>
>> Of course, modules can defer too - and I made some suggestions in my
>> waffle above the patch about that.
>>
> 
> < adding back trimmed, for fuller context >
> 
>>>>   	/* Sort as many dependencies as possible before exiting initcalls */
>>>>   	flush_workqueue(deferred_wq);
>>>> +
>>>> +	/* Now one final round, reporting any devices that remain deferred */
>>>> +	driver_deferred_probe_report = true;
>>>> +	driver_deferred_probe_trigger();
>>>> +	/* Sort as many dependencies as possible before exiting initcalls */
>>>> +	flush_workqueue(deferred_wq);
>>>> +
>>>>   	return 0;
>>>>   }


-- 
regards,
-grygorii

Re: Alternative approach to solve the deferred probe

[Russell King - ARM Linux]

On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote:
> On 10/21/2015 06:36 PM, Frank Rowand wrote:
> > The above is currently the last point for probe to succeed or defer
> > (until possibly, as you mentioned, module loading resolves the defer).
> > If a probe defers above, it will defer again below.  The set of defers
> > should be exactly the same above and below.
> > 
> 
> Unfortunately this is not "the last point for probe to succeed or defer".

Of course it isn't.  Being pedantic, there's actually no such thing,
because the point that the kernel as finished booting can never actually
be determined with things like modules being present.  That's something
I've acknowledged from the start of this.

> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
> Yes - they probably need to be updated to use module_init(), but that's what
> we have now). Those drivers will re-trigger deferred device probing if their
> probe succeeded.

Maybe this particular late_initcall() which triggers off the deferred
probing should be moved to its own really_late_initcall() which happens
as the very last thing - I think this is intended to run after everything
else has had a chance to probe once.

> As result, it is impossible to say when will it happen the 
> "final round of deferred device probing" :( and final list of drivers
> which was "deferred forever" will be know only when kernel exits to
> User space  ("deferred forever" - before loading modules).
> 
> May be, we also can consider adding debug_fs entry which can be used to
> display actual state of deferred_probe_pending_list? 

There are complaints in this thread about the existing deferred probing
implementation being hard to debug - where it's known that a device
has deferred, but it's not known why that happened.

That would be solved by my proposal, as this final round of probing
before entering userspace after _all_ normal device probes have been
attempted once and then we've tried to satisfy the deferred probe
(okay, that's what it's _supposed_ to be - and as it takes three lines
to write it, you'll excuse me if I just use the abbreviated "final
round of deferred probe" which is much shorter - but remember that
the long version is what I actually mean) would produce a list of
not only the devices that failed to probe, but also the cause of the
deferred probes.

My proposal would ensure that subsystems are happier to add these
prints, because in the normal scenario where we have deferred probing,
we're not littering the console log with lots of useless failure
messages which make people stop and think "now did device X probe?"
It also means scripts in our boot farms can more effectively analyse
the log and determine whether the boot was actually successful and
contained no errors.

Merely printing the list of devices which have been deferred is next
to useless.  The next question will always be "why did device X defer?"
and if that can't be answered, it means people having to spend a long
time adding lots of printks to the kernel at lots of -EPROBE_DEFER
returning sites or in the relevant drivers, tracing through the code
back towards the -EPROBE_DEFER sites to try and track it down.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Alternative approach to solve the deferred probe

[Russell King - ARM Linux]

On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote:
> On 10/21/2015 06:36 PM, Frank Rowand wrote:
> > The above is currently the last point for probe to succeed or defer
> > (until possibly, as you mentioned, module loading resolves the defer).
> > If a probe defers above, it will defer again below.  The set of defers
> > should be exactly the same above and below.
> > 
> 
> Unfortunately this is not "the last point for probe to succeed or defer".

Of course it isn't.  Being pedantic, there's actually no such thing,
because the point that the kernel as finished booting can never actually
be determined with things like modules being present.  That's something
I've acknowledged from the start of this.

> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
> Yes - they probably need to be updated to use module_init(), but that's what
> we have now). Those drivers will re-trigger deferred device probing if their
> probe succeeded.

Maybe this particular late_initcall() which triggers off the deferred
probing should be moved to its own really_late_initcall() which happens
as the very last thing - I think this is intended to run after everything
else has had a chance to probe once.

> As result, it is impossible to say when will it happen the 
> "final round of deferred device probing" :( and final list of drivers
> which was "deferred forever" will be know only when kernel exits to
> User space  ("deferred forever" - before loading modules).
> 
> May be, we also can consider adding debug_fs entry which can be used to
> display actual state of deferred_probe_pending_list? 

There are complaints in this thread about the existing deferred probing
implementation being hard to debug - where it's known that a device
has deferred, but it's not known why that happened.

That would be solved by my proposal, as this final round of probing
before entering userspace after _all_ normal device probes have been
attempted once and then we've tried to satisfy the deferred probe
(okay, that's what it's _supposed_ to be - and as it takes three lines
to write it, you'll excuse me if I just use the abbreviated "final
round of deferred probe" which is much shorter - but remember that
the long version is what I actually mean) would produce a list of
not only the devices that failed to probe, but also the cause of the
deferred probes.

My proposal would ensure that subsystems are happier to add these
prints, because in the normal scenario where we have deferred probing,
we're not littering the console log with lots of useless failure
messages which make people stop and think "now did device X probe?"
It also means scripts in our boot farms can more effectively analyse
the log and determine whether the boot was actually successful and
contained no errors.

Merely printing the list of devices which have been deferred is next
to useless.  The next question will always be "why did device X defer?"
and if that can't be answered, it means people having to spend a long
time adding lots of printks to the kernel at lots of -EPROBE_DEFER
returning sites or in the relevant drivers, tracing through the code
back towards the -EPROBE_DEFER sites to try and track it down.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Alternative approach to solve the deferred probe

[Russell King - ARM Linux]

On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote:
> On 10/21/2015 06:36 PM, Frank Rowand wrote:
> > The above is currently the last point for probe to succeed or defer
> > (until possibly, as you mentioned, module loading resolves the defer).
> > If a probe defers above, it will defer again below.  The set of defers
> > should be exactly the same above and below.
> > 
> 
> Unfortunately this is not "the last point for probe to succeed or defer".

Of course it isn't.  Being pedantic, there's actually no such thing,
because the point that the kernel as finished booting can never actually
be determined with things like modules being present.  That's something
I've acknowledged from the start of this.

> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
> Yes - they probably need to be updated to use module_init(), but that's what
> we have now). Those drivers will re-trigger deferred device probing if their
> probe succeeded.

Maybe this particular late_initcall() which triggers off the deferred
probing should be moved to its own really_late_initcall() which happens
as the very last thing - I think this is intended to run after everything
else has had a chance to probe once.

> As result, it is impossible to say when will it happen the 
> "final round of deferred device probing" :( and final list of drivers
> which was "deferred forever" will be know only when kernel exits to
> User space  ("deferred forever" - before loading modules).
> 
> May be, we also can consider adding debug_fs entry which can be used to
> display actual state of deferred_probe_pending_list? 

There are complaints in this thread about the existing deferred probing
implementation being hard to debug - where it's known that a device
has deferred, but it's not known why that happened.

That would be solved by my proposal, as this final round of probing
before entering userspace after _all_ normal device probes have been
attempted once and then we've tried to satisfy the deferred probe
(okay, that's what it's _supposed_ to be - and as it takes three lines
to write it, you'll excuse me if I just use the abbreviated "final
round of deferred probe" which is much shorter - but remember that
the long version is what I actually mean) would produce a list of
not only the devices that failed to probe, but also the cause of the
deferred probes.

My proposal would ensure that subsystems are happier to add these
prints, because in the normal scenario where we have deferred probing,
we're not littering the console log with lots of useless failure
messages which make people stop and think "now did device X probe?"
It also means scripts in our boot farms can more effectively analyse
the log and determine whether the boot was actually successful and
contained no errors.

Merely printing the list of devices which have been deferred is next
to useless.  The next question will always be "why did device X defer?"
and if that can't be answered, it means people having to spend a long
time adding lots of printks to the kernel at lots of -EPROBE_DEFER
returning sites or in the relevant drivers, tracing through the code
back towards the -EPROBE_DEFER sites to try and track it down.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/21/2015 9:55 AM, Grygorii Strashko wrote:
> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>
>> < snip >
>>
>>>>> +
>>>>>   static bool driver_deferred_probe_enable = false;
>>>>> +
>>>>>   /**
>>>>>    * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>>    *
>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>>   	driver_deferred_probe_trigger();
>>>>
>>>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>>>> not add another round of probes.
>>>
>>> The idea is not to report anything for drivers that were deferred
>>> during the normal bootup.  The above is part of the normal bootup,
>>> and the deferred activity should not be warned about.
>>
>> The above is currently the last point for probe to succeed or defer
>> (until possibly, as you mentioned, module loading resolves the defer).
>> If a probe defers above, it will defer again below.  The set of defers
>> should be exactly the same above and below.
>>
> 
> Unfortunately this is not "the last point for probe to succeed or defer".
> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);

Yes, cpsw_init() should _not_ be a late_initcall.  This is yet another
example of playing games with ordering probes that we have been trying
to eliminate.

Thanks for pointing out one of the resulting problems this causes for the
deferred probe mechanism.

> Yes - they probably need to be updated to use module_init(), but that's what
> we have now). Those drivers will re-trigger deferred device probing if their
> probe succeeded.

Yes, if cpsw_init() leads to a successful probe, then deferred device probing
will be re-triggered.  I do not know if cpsw_init() will be called before or
after deferred_probe_initcall().  The general initcall mechanism does not
provide any ordering guarantees between the two functions because they are
at the same initcall level.

> 
> As result, it is impossible to say when will it happen the 
> "final round of deferred device probing" :( and final list of drivers which
> was "deferred forever" will be know only when kernel exits to User space 
> ("deferred forever" - before loading modules).
> 
> May be, we also can consider adding debug_fs entry which can be used to display
> actual state of deferred_probe_pending_list? 
> 
>>>
>>> If we have any devices still deferring after _this_ round, that must
>>> indicate that some resource they want is not available, and that
>>> should be warned about.
>>>
>>> Of course, modules can defer too - and I made some suggestions in my
>>> waffle above the patch about that.
>>>
>>
>> < adding back trimmed, for fuller context >
>>
>>>>>   	/* Sort as many dependencies as possible before exiting initcalls */
>>>>>   	flush_workqueue(deferred_wq);
>>>>> +
>>>>> +	/* Now one final round, reporting any devices that remain deferred */
>>>>> +	driver_deferred_probe_report = true;
>>>>> +	driver_deferred_probe_trigger();
>>>>> +	/* Sort as many dependencies as possible before exiting initcalls */
>>>>> +	flush_workqueue(deferred_wq);
>>>>> +
>>>>>   	return 0;
>>>>>   }
> 
> 

Re: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/21/2015 9:55 AM, Grygorii Strashko wrote:
> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>
>> < snip >
>>
>>>>> +
>>>>>   static bool driver_deferred_probe_enable = false;
>>>>> +
>>>>>   /**
>>>>>    * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>>    *
>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>>   	driver_deferred_probe_trigger();
>>>>
>>>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>>>> not add another round of probes.
>>>
>>> The idea is not to report anything for drivers that were deferred
>>> during the normal bootup.  The above is part of the normal bootup,
>>> and the deferred activity should not be warned about.
>>
>> The above is currently the last point for probe to succeed or defer
>> (until possibly, as you mentioned, module loading resolves the defer).
>> If a probe defers above, it will defer again below.  The set of defers
>> should be exactly the same above and below.
>>
> 
> Unfortunately this is not "the last point for probe to succeed or defer".
> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);

Yes, cpsw_init() should _not_ be a late_initcall.  This is yet another
example of playing games with ordering probes that we have been trying
to eliminate.

Thanks for pointing out one of the resulting problems this causes for the
deferred probe mechanism.

> Yes - they probably need to be updated to use module_init(), but that's what
> we have now). Those drivers will re-trigger deferred device probing if their
> probe succeeded.

Yes, if cpsw_init() leads to a successful probe, then deferred device probing
will be re-triggered.  I do not know if cpsw_init() will be called before or
after deferred_probe_initcall().  The general initcall mechanism does not
provide any ordering guarantees between the two functions because they are
at the same initcall level.

> 
> As result, it is impossible to say when will it happen the 
> "final round of deferred device probing" :( and final list of drivers which
> was "deferred forever" will be know only when kernel exits to User space 
> ("deferred forever" - before loading modules).
> 
> May be, we also can consider adding debug_fs entry which can be used to display
> actual state of deferred_probe_pending_list? 
> 
>>>
>>> If we have any devices still deferring after _this_ round, that must
>>> indicate that some resource they want is not available, and that
>>> should be warned about.
>>>
>>> Of course, modules can defer too - and I made some suggestions in my
>>> waffle above the patch about that.
>>>
>>
>> < adding back trimmed, for fuller context >
>>
>>>>>   	/* Sort as many dependencies as possible before exiting initcalls */
>>>>>   	flush_workqueue(deferred_wq);
>>>>> +
>>>>> +	/* Now one final round, reporting any devices that remain deferred */
>>>>> +	driver_deferred_probe_report = true;
>>>>> +	driver_deferred_probe_trigger();
>>>>> +	/* Sort as many dependencies as possible before exiting initcalls */
>>>>> +	flush_workqueue(deferred_wq);
>>>>> +
>>>>>   	return 0;
>>>>>   }
> 
> 

Re: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/21/2015 9:55 AM, Grygorii Strashko wrote:
> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>
>> < snip >
>>
>>>>> +
>>>>>   static bool driver_deferred_probe_enable = false;
>>>>> +
>>>>>   /**
>>>>>    * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>>    *
>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>>   	driver_deferred_probe_trigger();
>>>>
>>>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>>>> not add another round of probes.
>>>
>>> The idea is not to report anything for drivers that were deferred
>>> during the normal bootup.  The above is part of the normal bootup,
>>> and the deferred activity should not be warned about.
>>
>> The above is currently the last point for probe to succeed or defer
>> (until possibly, as you mentioned, module loading resolves the defer).
>> If a probe defers above, it will defer again below.  The set of defers
>> should be exactly the same above and below.
>>
> 
> Unfortunately this is not "the last point for probe to succeed or defer".
> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);

Yes, cpsw_init() should _not_ be a late_initcall.  This is yet another
example of playing games with ordering probes that we have been trying
to eliminate.

Thanks for pointing out one of the resulting problems this causes for the
deferred probe mechanism.

> Yes - they probably need to be updated to use module_init(), but that's what
> we have now). Those drivers will re-trigger deferred device probing if their
> probe succeeded.

Yes, if cpsw_init() leads to a successful probe, then deferred device probing
will be re-triggered.  I do not know if cpsw_init() will be called before or
after deferred_probe_initcall().  The general initcall mechanism does not
provide any ordering guarantees between the two functions because they are
at the same initcall level.

> 
> As result, it is impossible to say when will it happen the 
> "final round of deferred device probing" :( and final list of drivers which
> was "deferred forever" will be know only when kernel exits to User space 
> ("deferred forever" - before loading modules).
> 
> May be, we also can consider adding debug_fs entry which can be used to display
> actual state of deferred_probe_pending_list? 
> 
>>>
>>> If we have any devices still deferring after _this_ round, that must
>>> indicate that some resource they want is not available, and that
>>> should be warned about.
>>>
>>> Of course, modules can defer too - and I made some suggestions in my
>>> waffle above the patch about that.
>>>
>>
>> < adding back trimmed, for fuller context >
>>
>>>>>   	/* Sort as many dependencies as possible before exiting initcalls */
>>>>>   	flush_workqueue(deferred_wq);
>>>>> +
>>>>> +	/* Now one final round, reporting any devices that remain deferred */
>>>>> +	driver_deferred_probe_report = true;
>>>>> +	driver_deferred_probe_trigger();
>>>>> +	/* Sort as many dependencies as possible before exiting initcalls */
>>>>> +	flush_workqueue(deferred_wq);
>>>>> +
>>>>>   	return 0;
>>>>>   }
> 
> 

Re: Alternative approach to solve the deferred probe

[Grygorii Strashko]

Hi Russell,

On 10/21/2015 08:20 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote:
>> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>>> The above is currently the last point for probe to succeed or defer
>>> (until possibly, as you mentioned, module loading resolves the defer).
>>> If a probe defers above, it will defer again below.  The set of defers
>>> should be exactly the same above and below.
>>>
>>
>> Unfortunately this is not "the last point for probe to succeed or defer".
> 
> Of course it isn't.  Being pedantic, there's actually no such thing,
> because the point that the kernel as finished booting can never actually
> be determined with things like modules being present.  That's something
> I've acknowledged from the start of this.
> 
>> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
>> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
>> Yes - they probably need to be updated to use module_init(), but that's what
>> we have now). Those drivers will re-trigger deferred device probing if their
>> probe succeeded.
> 
> Maybe this particular late_initcall() which triggers off the deferred
> probing should be moved to its own really_late_initcall() which happens
> as the very last thing - I think this is intended to run after everything
> else has had a chance to probe once.
> 
>> As result, it is impossible to say when will it happen the
>> "final round of deferred device probing" :( and final list of drivers
>> which was "deferred forever" will be know only when kernel exits to
>> User space  ("deferred forever" - before loading modules).
>>
>> May be, we also can consider adding debug_fs entry which can be used to
>> display actual state of deferred_probe_pending_list?
> 
> There are complaints in this thread about the existing deferred probing
> implementation being hard to debug - where it's known that a device
> has deferred, but it's not known why that happened.
> 
> That would be solved by my proposal, as this final round of probing
> before entering userspace after _all_ normal device probes have been
> attempted once and then we've tried to satisfy the deferred probe
> (okay, that's what it's _supposed_ to be - and as it takes three lines
> to write it, you'll excuse me if I just use the abbreviated "final
> round of deferred probe" which is much shorter - but remember that
> the long version is what I actually mean) would produce a list of
> not only the devices that failed to probe, but also the cause of the
> deferred probes.
> 
> My proposal would ensure that subsystems are happier to add these
> prints, because in the normal scenario where we have deferred probing,
> we're not littering the console log with lots of useless failure
> messages which make people stop and think "now did device X probe?"
> It also means scripts in our boot farms can more effectively analyse
> the log and determine whether the boot was actually successful and
> contained no errors.
> 
> Merely printing the list of devices which have been deferred is next
> to useless.  The next question will always be "why did device X defer?"
> and if that can't be answered, it means people having to spend a long
> time adding lots of printks to the kernel at lots of -EPROBE_DEFER
> returning sites or in the relevant drivers, tracing through the code
> back towards the -EPROBE_DEFER sites to try and track it down.
> 

I perfectly understand your proposal and spent a lot of time trying to
debug such kind issues also (and using printks).  

But I worry a bit (and that my main point) about these few additional
rounds of deferred device probing which I have right now and which allows
some of drivers to finish, finally, their probes successfully.
With proposed change I'll get more messages in boot log, but some of
them will belong to drivers which have been probed successfully and so,
they will be not really useful.

As result, I think, the most important thing is to identify (or create)
some point during kernel boot when it will be possible to say that all
built-in drivers (at least) finish their probes 100% (done or defer).

Might be do_initcalls() can be updated (smth like this):
static void __init do_initcalls(void)
{
	int level;

	for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
		do_initcall_level(level);

+	wait_for_device_probe();
+	/* Now one final round, reporting any devices that remain deferred */
+	driver_deferred_probe_report = true;
+	driver_deferred_probe_trigger();
+	wait_for_device_probe();
}

Also, in my opinion, it will be useful if this debugging feature will be optional.

Thanks.
-- 
regards,
-grygorii
S/ILKP

Re: Alternative approach to solve the deferred probe

[Grygorii Strashko]

Hi Russell,

On 10/21/2015 08:20 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote:
>> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>>> The above is currently the last point for probe to succeed or defer
>>> (until possibly, as you mentioned, module loading resolves the defer).
>>> If a probe defers above, it will defer again below.  The set of defers
>>> should be exactly the same above and below.
>>>
>>
>> Unfortunately this is not "the last point for probe to succeed or defer".
> 
> Of course it isn't.  Being pedantic, there's actually no such thing,
> because the point that the kernel as finished booting can never actually
> be determined with things like modules being present.  That's something
> I've acknowledged from the start of this.
> 
>> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
>> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
>> Yes - they probably need to be updated to use module_init(), but that's what
>> we have now). Those drivers will re-trigger deferred device probing if their
>> probe succeeded.
> 
> Maybe this particular late_initcall() which triggers off the deferred
> probing should be moved to its own really_late_initcall() which happens
> as the very last thing - I think this is intended to run after everything
> else has had a chance to probe once.
> 
>> As result, it is impossible to say when will it happen the
>> "final round of deferred device probing" :( and final list of drivers
>> which was "deferred forever" will be know only when kernel exits to
>> User space  ("deferred forever" - before loading modules).
>>
>> May be, we also can consider adding debug_fs entry which can be used to
>> display actual state of deferred_probe_pending_list?
> 
> There are complaints in this thread about the existing deferred probing
> implementation being hard to debug - where it's known that a device
> has deferred, but it's not known why that happened.
> 
> That would be solved by my proposal, as this final round of probing
> before entering userspace after _all_ normal device probes have been
> attempted once and then we've tried to satisfy the deferred probe
> (okay, that's what it's _supposed_ to be - and as it takes three lines
> to write it, you'll excuse me if I just use the abbreviated "final
> round of deferred probe" which is much shorter - but remember that
> the long version is what I actually mean) would produce a list of
> not only the devices that failed to probe, but also the cause of the
> deferred probes.
> 
> My proposal would ensure that subsystems are happier to add these
> prints, because in the normal scenario where we have deferred probing,
> we're not littering the console log with lots of useless failure
> messages which make people stop and think "now did device X probe?"
> It also means scripts in our boot farms can more effectively analyse
> the log and determine whether the boot was actually successful and
> contained no errors.
> 
> Merely printing the list of devices which have been deferred is next
> to useless.  The next question will always be "why did device X defer?"
> and if that can't be answered, it means people having to spend a long
> time adding lots of printks to the kernel at lots of -EPROBE_DEFER
> returning sites or in the relevant drivers, tracing through the code
> back towards the -EPROBE_DEFER sites to try and track it down.
> 

I perfectly understand your proposal and spent a lot of time trying to
debug such kind issues also (and using printks).  

But I worry a bit (and that my main point) about these few additional
rounds of deferred device probing which I have right now and which allows
some of drivers to finish, finally, their probes successfully.
With proposed change I'll get more messages in boot log, but some of
them will belong to drivers which have been probed successfully and so,
they will be not really useful.

As result, I think, the most important thing is to identify (or create)
some point during kernel boot when it will be possible to say that all
built-in drivers (at least) finish their probes 100% (done or defer).

Might be do_initcalls() can be updated (smth like this):
static void __init do_initcalls(void)
{
	int level;

	for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
		do_initcall_level(level);

+	wait_for_device_probe();
+	/* Now one final round, reporting any devices that remain deferred */
+	driver_deferred_probe_report = true;
+	driver_deferred_probe_trigger();
+	wait_for_device_probe();
}

Also, in my opinion, it will be useful if this debugging feature will be optional.

Thanks.
-- 
regards,
-grygorii
S/ILKP

Re: Alternative approach to solve the deferred probe

[Grygorii Strashko]

Hi Russell,

On 10/21/2015 08:20 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote:
>> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>>> The above is currently the last point for probe to succeed or defer
>>> (until possibly, as you mentioned, module loading resolves the defer).
>>> If a probe defers above, it will defer again below.  The set of defers
>>> should be exactly the same above and below.
>>>
>>
>> Unfortunately this is not "the last point for probe to succeed or defer".
> 
> Of course it isn't.  Being pedantic, there's actually no such thing,
> because the point that the kernel as finished booting can never actually
> be determined with things like modules being present.  That's something
> I've acknowledged from the start of this.
> 
>> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
>> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
>> Yes - they probably need to be updated to use module_init(), but that's what
>> we have now). Those drivers will re-trigger deferred device probing if their
>> probe succeeded.
> 
> Maybe this particular late_initcall() which triggers off the deferred
> probing should be moved to its own really_late_initcall() which happens
> as the very last thing - I think this is intended to run after everything
> else has had a chance to probe once.
> 
>> As result, it is impossible to say when will it happen the
>> "final round of deferred device probing" :( and final list of drivers
>> which was "deferred forever" will be know only when kernel exits to
>> User space  ("deferred forever" - before loading modules).
>>
>> May be, we also can consider adding debug_fs entry which can be used to
>> display actual state of deferred_probe_pending_list?
> 
> There are complaints in this thread about the existing deferred probing
> implementation being hard to debug - where it's known that a device
> has deferred, but it's not known why that happened.
> 
> That would be solved by my proposal, as this final round of probing
> before entering userspace after _all_ normal device probes have been
> attempted once and then we've tried to satisfy the deferred probe
> (okay, that's what it's _supposed_ to be - and as it takes three lines
> to write it, you'll excuse me if I just use the abbreviated "final
> round of deferred probe" which is much shorter - but remember that
> the long version is what I actually mean) would produce a list of
> not only the devices that failed to probe, but also the cause of the
> deferred probes.
> 
> My proposal would ensure that subsystems are happier to add these
> prints, because in the normal scenario where we have deferred probing,
> we're not littering the console log with lots of useless failure
> messages which make people stop and think "now did device X probe?"
> It also means scripts in our boot farms can more effectively analyse
> the log and determine whether the boot was actually successful and
> contained no errors.
> 
> Merely printing the list of devices which have been deferred is next
> to useless.  The next question will always be "why did device X defer?"
> and if that can't be answered, it means people having to spend a long
> time adding lots of printks to the kernel at lots of -EPROBE_DEFER
> returning sites or in the relevant drivers, tracing through the code
> back towards the -EPROBE_DEFER sites to try and track it down.
> 

I perfectly understand your proposal and spent a lot of time trying to
debug such kind issues also (and using printks).  

But I worry a bit (and that my main point) about these few additional
rounds of deferred device probing which I have right now and which allows
some of drivers to finish, finally, their probes successfully.
With proposed change I'll get more messages in boot log, but some of
them will belong to drivers which have been probed successfully and so,
they will be not really useful.

As result, I think, the most important thing is to identify (or create)
some point during kernel boot when it will be possible to say that all
built-in drivers (at least) finish their probes 100% (done or defer).

Might be do_initcalls() can be updated (smth like this):
static void __init do_initcalls(void)
{
	int level;

	for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
		do_initcall_level(level);

+	wait_for_device_probe();
+	/* Now one final round, reporting any devices that remain deferred */
+	driver_deferred_probe_report = true;
+	driver_deferred_probe_trigger();
+	wait_for_device_probe();
}

Also, in my opinion, it will be useful if this debugging feature will be optional.

Thanks.
-- 
regards,
-grygorii
S/ILKP

Re: [GIT PULL] On-demand device probing

[Frank Rowand]

On 10/21/2015 9:27 AM, Mark Brown wrote:
> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> 
>>> To be clear, I was saying that this series should NOT affect total
>>> boot times much.
> 
>> I'm confused.  If I understood correctly, improving boot time was
>> the key justification for accepting this patch set.  For example,
>> from "[PATCH v7 0/20] On-demand device probing":
>>
>>    I have a problem with the panel on my Tegra Chromebook taking longer
>>    than expected to be ready during boot (Stéphane Marchesin reported what
>>    is basically the same issue in [0]), and have looked into ordered
>>    probing as a better way of solving this than moving nodes around in the
>>    DT or playing with initcall levels and linking order.
>>
>>    ...
>>
>>    With this series I get the kernel to output to the panel in 0.5s,
>>    instead of 2.8s.
> 
> Overall boot time and time to get some individual built in component up
> and running aren't the same thing - what this'll do is get things up
> more in the link order of the leaf consumers rather than deferring those
> leaf consumers when their dependencies aren't ready yet.

Thanks!  I read too much into what was being improved.

So this patch series, which on other merits may be a good idea, is as
a by product solving a specific ordering issue, moving successful panel
initialization to an earlier point in the boot sequence, if I now
understand more correctly.

In that context, this seems like yet another ad hoc way of causing the
probe order to change in a way to solves one specific issue?  Could
it just as likely move the boot order of some other driver on some
other board later, to the detriment of somebody else?


> 
>> While not as dramatic as your results, they are somewhat supportive.
>> What has changed your assessment that the on-demand device probing
>> patches will give a big boot performance increase?  Do you have
>> new data or analysis?
> 
> See above, my understanding was that the performance improvements were
> more around improved control/predictability/handwave of the boot
> ordering rather than total time.
> 

Re: [GIT PULL] On-demand device probing

[Frank Rowand]

On 10/21/2015 9:27 AM, Mark Brown wrote:
> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> 
>>> To be clear, I was saying that this series should NOT affect total
>>> boot times much.
> 
>> I'm confused.  If I understood correctly, improving boot time was
>> the key justification for accepting this patch set.  For example,
>> from "[PATCH v7 0/20] On-demand device probing":
>>
>>    I have a problem with the panel on my Tegra Chromebook taking longer
>>    than expected to be ready during boot (Stéphane Marchesin reported what
>>    is basically the same issue in [0]), and have looked into ordered
>>    probing as a better way of solving this than moving nodes around in the
>>    DT or playing with initcall levels and linking order.
>>
>>    ...
>>
>>    With this series I get the kernel to output to the panel in 0.5s,
>>    instead of 2.8s.
> 
> Overall boot time and time to get some individual built in component up
> and running aren't the same thing - what this'll do is get things up
> more in the link order of the leaf consumers rather than deferring those
> leaf consumers when their dependencies aren't ready yet.

Thanks!  I read too much into what was being improved.

So this patch series, which on other merits may be a good idea, is as
a by product solving a specific ordering issue, moving successful panel
initialization to an earlier point in the boot sequence, if I now
understand more correctly.

In that context, this seems like yet another ad hoc way of causing the
probe order to change in a way to solves one specific issue?  Could
it just as likely move the boot order of some other driver on some
other board later, to the detriment of somebody else?


> 
>> While not as dramatic as your results, they are somewhat supportive.
>> What has changed your assessment that the on-demand device probing
>> patches will give a big boot performance increase?  Do you have
>> new data or analysis?
> 
> See above, my understanding was that the performance improvements were
> more around improved control/predictability/handwave of the boot
> ordering rather than total time.
> 

Re: [GIT PULL] On-demand device probing

[Frank Rowand]

On 10/21/2015 9:27 AM, Mark Brown wrote:
> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> 
>>> To be clear, I was saying that this series should NOT affect total
>>> boot times much.
> 
>> I'm confused.  If I understood correctly, improving boot time was
>> the key justification for accepting this patch set.  For example,
>> from "[PATCH v7 0/20] On-demand device probing":
>>
>>    I have a problem with the panel on my Tegra Chromebook taking longer
>>    than expected to be ready during boot (Stéphane Marchesin reported what
>>    is basically the same issue in [0]), and have looked into ordered
>>    probing as a better way of solving this than moving nodes around in the
>>    DT or playing with initcall levels and linking order.
>>
>>    ...
>>
>>    With this series I get the kernel to output to the panel in 0.5s,
>>    instead of 2.8s.
> 
> Overall boot time and time to get some individual built in component up
> and running aren't the same thing - what this'll do is get things up
> more in the link order of the leaf consumers rather than deferring those
> leaf consumers when their dependencies aren't ready yet.

Thanks!  I read too much into what was being improved.

So this patch series, which on other merits may be a good idea, is as
a by product solving a specific ordering issue, moving successful panel
initialization to an earlier point in the boot sequence, if I now
understand more correctly.

In that context, this seems like yet another ad hoc way of causing the
probe order to change in a way to solves one specific issue?  Could
it just as likely move the boot order of some other driver on some
other board later, to the detriment of somebody else?


> 
>> While not as dramatic as your results, they are somewhat supportive.
>> What has changed your assessment that the on-demand device probing
>> patches will give a big boot performance increase?  Do you have
>> new data or analysis?
> 
> See above, my understanding was that the performance improvements were
> more around improved control/predictability/handwave of the boot
> ordering rather than total time.
> 

Re: Alternative approach to solve the deferred probe

[Russell King - ARM Linux]

On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
> But I worry a bit (and that my main point) about these few additional
> rounds of deferred device probing which I have right now and which allows
> some of drivers to finish, finally, their probes successfully.
> With proposed change I'll get more messages in boot log, but some of
> them will belong to drivers which have been probed successfully and so,
> they will be not really useful.

Then you haven't properly understood my proposal.

I want to get rid of all the "X deferred its probing" messages up until
the point that we set the "please report deferred probes" flag.

That _should_ mean that all the deferred probing that goes on becomes
_totally_ silent and becomes hidden (unless you really want to see it,
in which case we can make a debug option which turns it on) up until
we're at the point where we want to enter userspace.

At that point, we then report into the kernel log which devices are
still deferring and, via appropriately placed dev_warn_deferred(),
the reasons why the devices are being deferred.

So, gone will be all the messages earlier in the log about device X
not having a GPIO/clock/whatever because the device providing the
GPIO/clock/whatever hasn't been probed.

If everything is satisfied by the time we run this last round (again,
I'm not using a three line sentence to describe exactly what I mean,
I'm sure you know by now... oops, I just did) then the kernel will
report nothing about any deferrals.  That's _got_ to be an improvement.

> 
> As result, I think, the most important thing is to identify (or create)
> some point during kernel boot when it will be possible to say that all
> built-in drivers (at least) finish their probes 100% (done or defer).
> 
> Might be do_initcalls() can be updated (smth like this):
> static void __init do_initcalls(void)
> {
> 	int level;
> 
> 	for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
> 		do_initcall_level(level);
> 
> +	wait_for_device_probe();
> +	/* Now one final round, reporting any devices that remain deferred */
> +	driver_deferred_probe_report = true;
> +	driver_deferred_probe_trigger();
> +	wait_for_device_probe();
> }
> 
> Also, in my opinion, it will be useful if this debugging feature will be
> optional.

I wonder why you want it optional... so I'm going to guess and cover
both cases I can think of below to head off another round of reply on
this point (sorry if this sucks eggs.)

I don't see it as being optional, because it's going to be cheap to run
in the case of a system which has very few or no errors - which is what
you should have for production systems, right?

Remember, only devices and drivers that are present and have been
probed once get added to the deferred probe list, not devices for
which their drivers are modules.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Alternative approach to solve the deferred probe

[Russell King - ARM Linux]

On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
> But I worry a bit (and that my main point) about these few additional
> rounds of deferred device probing which I have right now and which allows
> some of drivers to finish, finally, their probes successfully.
> With proposed change I'll get more messages in boot log, but some of
> them will belong to drivers which have been probed successfully and so,
> they will be not really useful.

Then you haven't properly understood my proposal.

I want to get rid of all the "X deferred its probing" messages up until
the point that we set the "please report deferred probes" flag.

That _should_ mean that all the deferred probing that goes on becomes
_totally_ silent and becomes hidden (unless you really want to see it,
in which case we can make a debug option which turns it on) up until
we're at the point where we want to enter userspace.

At that point, we then report into the kernel log which devices are
still deferring and, via appropriately placed dev_warn_deferred(),
the reasons why the devices are being deferred.

So, gone will be all the messages earlier in the log about device X
not having a GPIO/clock/whatever because the device providing the
GPIO/clock/whatever hasn't been probed.

If everything is satisfied by the time we run this last round (again,
I'm not using a three line sentence to describe exactly what I mean,
I'm sure you know by now... oops, I just did) then the kernel will
report nothing about any deferrals.  That's _got_ to be an improvement.

> 
> As result, I think, the most important thing is to identify (or create)
> some point during kernel boot when it will be possible to say that all
> built-in drivers (at least) finish their probes 100% (done or defer).
> 
> Might be do_initcalls() can be updated (smth like this):
> static void __init do_initcalls(void)
> {
> 	int level;
> 
> 	for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
> 		do_initcall_level(level);
> 
> +	wait_for_device_probe();
> +	/* Now one final round, reporting any devices that remain deferred */
> +	driver_deferred_probe_report = true;
> +	driver_deferred_probe_trigger();
> +	wait_for_device_probe();
> }
> 
> Also, in my opinion, it will be useful if this debugging feature will be
> optional.

I wonder why you want it optional... so I'm going to guess and cover
both cases I can think of below to head off another round of reply on
this point (sorry if this sucks eggs.)

I don't see it as being optional, because it's going to be cheap to run
in the case of a system which has very few or no errors - which is what
you should have for production systems, right?

Remember, only devices and drivers that are present and have been
probed once get added to the deferred probe list, not devices for
which their drivers are modules.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Alternative approach to solve the deferred probe

[Russell King - ARM Linux]

On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
> But I worry a bit (and that my main point) about these few additional
> rounds of deferred device probing which I have right now and which allows
> some of drivers to finish, finally, their probes successfully.
> With proposed change I'll get more messages in boot log, but some of
> them will belong to drivers which have been probed successfully and so,
> they will be not really useful.

Then you haven't properly understood my proposal.

I want to get rid of all the "X deferred its probing" messages up until
the point that we set the "please report deferred probes" flag.

That _should_ mean that all the deferred probing that goes on becomes
_totally_ silent and becomes hidden (unless you really want to see it,
in which case we can make a debug option which turns it on) up until
we're at the point where we want to enter userspace.

At that point, we then report into the kernel log which devices are
still deferring and, via appropriately placed dev_warn_deferred(),
the reasons why the devices are being deferred.

So, gone will be all the messages earlier in the log about device X
not having a GPIO/clock/whatever because the device providing the
GPIO/clock/whatever hasn't been probed.

If everything is satisfied by the time we run this last round (again,
I'm not using a three line sentence to describe exactly what I mean,
I'm sure you know by now... oops, I just did) then the kernel will
report nothing about any deferrals.  That's _got_ to be an improvement.

> 
> As result, I think, the most important thing is to identify (or create)
> some point during kernel boot when it will be possible to say that all
> built-in drivers (at least) finish their probes 100% (done or defer).
> 
> Might be do_initcalls() can be updated (smth like this):
> static void __init do_initcalls(void)
> {
> 	int level;
> 
> 	for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
> 		do_initcall_level(level);
> 
> +	wait_for_device_probe();
> +	/* Now one final round, reporting any devices that remain deferred */
> +	driver_deferred_probe_report = true;
> +	driver_deferred_probe_trigger();
> +	wait_for_device_probe();
> }
> 
> Also, in my opinion, it will be useful if this debugging feature will be
> optional.

I wonder why you want it optional... so I'm going to guess and cover
both cases I can think of below to head off another round of reply on
this point (sorry if this sucks eggs.)

I don't see it as being optional, because it's going to be cheap to run
in the case of a system which has very few or no errors - which is what
you should have for production systems, right?

Remember, only devices and drivers that are present and have been
probed once get added to the deferred probe list, not devices for
which their drivers are modules.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Alternative approach to solve the deferred probe

[Grygorii Strashko]

On 10/21/2015 09:02 PM, Frank Rowand wrote:
> On 10/21/2015 9:55 AM, Grygorii Strashko wrote:
>> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>>
>>> < snip >
>>>
>>>>>> +
>>>>>>    static bool driver_deferred_probe_enable = false;
>>>>>> +
>>>>>>    /**
>>>>>>     * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>>>     *
>>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>>>    	driver_deferred_probe_trigger();
>>>>>
>>>>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>>>>> not add another round of probes.
>>>>
>>>> The idea is not to report anything for drivers that were deferred
>>>> during the normal bootup.  The above is part of the normal bootup,
>>>> and the deferred activity should not be warned about.
>>>
>>> The above is currently the last point for probe to succeed or defer
>>> (until possibly, as you mentioned, module loading resolves the defer).
>>> If a probe defers above, it will defer again below.  The set of defers
>>> should be exactly the same above and below.
>>>
>>
>> Unfortunately this is not "the last point for probe to succeed or defer".
>> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
>> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
> 
> Yes, cpsw_init() should _not_ be a late_initcall.  This is yet another
> example of playing games with ordering probes that we have been trying
> to eliminate.

yes, we're trying to solve such issues and have all TI's drivers initialized
from module_init() level, but as usual this process is not so fast. 

You know, some times ago there was no other way to solve boot ordering issues,
but only to play with init levels :) And, as result, right now in drivers/
and sound/ folders there are >77 occurrences of late_initcall(). 

> 
> Thanks for pointing out one of the resulting problems this causes for the
> deferred probe mechanism.
> 
>> Yes - they probably need to be updated to use module_init(), but that's what
>> we have now). Those drivers will re-trigger deferred device probing if their
>> probe succeeded.
> 
> Yes, if cpsw_init() leads to a successful probe, then deferred device probing
> will be re-triggered.  I do not know if cpsw_init() will be called before or
> after deferred_probe_initcall().  The general initcall mechanism does not
> provide any ordering guarantees between the two functions because they are
> at the same initcall level.

It will be called after and it will re-triggered deferred device probing.
Now ordering of init calls will be specified by drivers/Makefile
which itself is funny thing.

> 
>>
>> As result, it is impossible to say when will it happen the
>> "final round of deferred device probing" :( and final list of drivers which
>> was "deferred forever" will be know only when kernel exits to User space
>> ("deferred forever" - before loading modules).
>>
>> May be, we also can consider adding debug_fs entry which can be used to display
>> actual state of deferred_probe_pending_list?
>>
>>>>
>>>> If we have any devices still deferring after _this_ round, that must
>>>> indicate that some resource they want is not available, and that
>>>> should be warned about.
>>>>
>>>> Of course, modules can defer too - and I made some suggestions in my
>>>> waffle above the patch about that.
>>>>
>>>
>>> < adding back trimmed, for fuller context >
>>>
>>>>>>    	/* Sort as many dependencies as possible before exiting initcalls */
>>>>>>    	flush_workqueue(deferred_wq);
>>>>>> +
>>>>>> +	/* Now one final round, reporting any devices that remain deferred */
>>>>>> +	driver_deferred_probe_report = true;
>>>>>> +	driver_deferred_probe_trigger();
>>>>>> +	/* Sort as many dependencies as possible before exiting initcalls */
>>>>>> +	flush_workqueue(deferred_wq);
>>>>>> +
>>>>>>    	return 0;
>>>>>>    }
>>
>>
> 


-- 
regards,
-grygorii

Re: Alternative approach to solve the deferred probe

[Grygorii Strashko]

On 10/21/2015 09:02 PM, Frank Rowand wrote:
> On 10/21/2015 9:55 AM, Grygorii Strashko wrote:
>> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>>
>>> < snip >
>>>
>>>>>> +
>>>>>>    static bool driver_deferred_probe_enable = false;
>>>>>> +
>>>>>>    /**
>>>>>>     * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>>>     *
>>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>>>    	driver_deferred_probe_trigger();
>>>>>
>>>>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>>>>> not add another round of probes.
>>>>
>>>> The idea is not to report anything for drivers that were deferred
>>>> during the normal bootup.  The above is part of the normal bootup,
>>>> and the deferred activity should not be warned about.
>>>
>>> The above is currently the last point for probe to succeed or defer
>>> (until possibly, as you mentioned, module loading resolves the defer).
>>> If a probe defers above, it will defer again below.  The set of defers
>>> should be exactly the same above and below.
>>>
>>
>> Unfortunately this is not "the last point for probe to succeed or defer".
>> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
>> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
> 
> Yes, cpsw_init() should _not_ be a late_initcall.  This is yet another
> example of playing games with ordering probes that we have been trying
> to eliminate.

yes, we're trying to solve such issues and have all TI's drivers initialized
from module_init() level, but as usual this process is not so fast. 

You know, some times ago there was no other way to solve boot ordering issues,
but only to play with init levels :) And, as result, right now in drivers/
and sound/ folders there are >77 occurrences of late_initcall(). 

> 
> Thanks for pointing out one of the resulting problems this causes for the
> deferred probe mechanism.
> 
>> Yes - they probably need to be updated to use module_init(), but that's what
>> we have now). Those drivers will re-trigger deferred device probing if their
>> probe succeeded.
> 
> Yes, if cpsw_init() leads to a successful probe, then deferred device probing
> will be re-triggered.  I do not know if cpsw_init() will be called before or
> after deferred_probe_initcall().  The general initcall mechanism does not
> provide any ordering guarantees between the two functions because they are
> at the same initcall level.

It will be called after and it will re-triggered deferred device probing.
Now ordering of init calls will be specified by drivers/Makefile
which itself is funny thing.

> 
>>
>> As result, it is impossible to say when will it happen the
>> "final round of deferred device probing" :( and final list of drivers which
>> was "deferred forever" will be know only when kernel exits to User space
>> ("deferred forever" - before loading modules).
>>
>> May be, we also can consider adding debug_fs entry which can be used to display
>> actual state of deferred_probe_pending_list?
>>
>>>>
>>>> If we have any devices still deferring after _this_ round, that must
>>>> indicate that some resource they want is not available, and that
>>>> should be warned about.
>>>>
>>>> Of course, modules can defer too - and I made some suggestions in my
>>>> waffle above the patch about that.
>>>>
>>>
>>> < adding back trimmed, for fuller context >
>>>
>>>>>>    	/* Sort as many dependencies as possible before exiting initcalls */
>>>>>>    	flush_workqueue(deferred_wq);
>>>>>> +
>>>>>> +	/* Now one final round, reporting any devices that remain deferred */
>>>>>> +	driver_deferred_probe_report = true;
>>>>>> +	driver_deferred_probe_trigger();
>>>>>> +	/* Sort as many dependencies as possible before exiting initcalls */
>>>>>> +	flush_workqueue(deferred_wq);
>>>>>> +
>>>>>>    	return 0;
>>>>>>    }
>>
>>
> 


-- 
regards,
-grygorii

Re: Alternative approach to solve the deferred probe

[Grygorii Strashko]

On 10/21/2015 09:02 PM, Frank Rowand wrote:
> On 10/21/2015 9:55 AM, Grygorii Strashko wrote:
>> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>>
>>> < snip >
>>>
>>>>>> +
>>>>>>    static bool driver_deferred_probe_enable = false;
>>>>>> +
>>>>>>    /**
>>>>>>     * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>>>     *
>>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>>>    	driver_deferred_probe_trigger();
>>>>>
>>>>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>>>>> not add another round of probes.
>>>>
>>>> The idea is not to report anything for drivers that were deferred
>>>> during the normal bootup.  The above is part of the normal bootup,
>>>> and the deferred activity should not be warned about.
>>>
>>> The above is currently the last point for probe to succeed or defer
>>> (until possibly, as you mentioned, module loading resolves the defer).
>>> If a probe defers above, it will defer again below.  The set of defers
>>> should be exactly the same above and below.
>>>
>>
>> Unfortunately this is not "the last point for probe to succeed or defer".
>> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
>> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
> 
> Yes, cpsw_init() should _not_ be a late_initcall.  This is yet another
> example of playing games with ordering probes that we have been trying
> to eliminate.

yes, we're trying to solve such issues and have all TI's drivers initialized
from module_init() level, but as usual this process is not so fast. 

You know, some times ago there was no other way to solve boot ordering issues,
but only to play with init levels :) And, as result, right now in drivers/
and sound/ folders there are >77 occurrences of late_initcall(). 

> 
> Thanks for pointing out one of the resulting problems this causes for the
> deferred probe mechanism.
> 
>> Yes - they probably need to be updated to use module_init(), but that's what
>> we have now). Those drivers will re-trigger deferred device probing if their
>> probe succeeded.
> 
> Yes, if cpsw_init() leads to a successful probe, then deferred device probing
> will be re-triggered.  I do not know if cpsw_init() will be called before or
> after deferred_probe_initcall().  The general initcall mechanism does not
> provide any ordering guarantees between the two functions because they are
> at the same initcall level.

It will be called after and it will re-triggered deferred device probing.
Now ordering of init calls will be specified by drivers/Makefile
which itself is funny thing.

> 
>>
>> As result, it is impossible to say when will it happen the
>> "final round of deferred device probing" :( and final list of drivers which
>> was "deferred forever" will be know only when kernel exits to User space
>> ("deferred forever" - before loading modules).
>>
>> May be, we also can consider adding debug_fs entry which can be used to display
>> actual state of deferred_probe_pending_list?
>>
>>>>
>>>> If we have any devices still deferring after _this_ round, that must
>>>> indicate that some resource they want is not available, and that
>>>> should be warned about.
>>>>
>>>> Of course, modules can defer too - and I made some suggestions in my
>>>> waffle above the patch about that.
>>>>
>>>
>>> < adding back trimmed, for fuller context >
>>>
>>>>>>    	/* Sort as many dependencies as possible before exiting initcalls */
>>>>>>    	flush_workqueue(deferred_wq);
>>>>>> +
>>>>>> +	/* Now one final round, reporting any devices that remain deferred */
>>>>>> +	driver_deferred_probe_report = true;
>>>>>> +	driver_deferred_probe_trigger();
>>>>>> +	/* Sort as many dependencies as possible before exiting initcalls */
>>>>>> +	flush_workqueue(deferred_wq);
>>>>>> +
>>>>>>    	return 0;
>>>>>>    }
>>
>>
> 


-- 
regards,
-grygorii

Re: Alternative approach to solve the deferred probe

[Russell King - ARM Linux]

On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote:
> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
> > On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
> >> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> 
> < snip >
> 
> >>> +
> >>>  static bool driver_deferred_probe_enable = false;
> >>> +
> >>>  /**
> >>>   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
> >>>   *
> >>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
> >>>  	driver_deferred_probe_trigger();
> >>
> >> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
> >> not add another round of probes.
> > 
> > The idea is not to report anything for drivers that were deferred
> > during the normal bootup.  The above is part of the normal bootup,
> > and the deferred activity should not be warned about.
> 
> The above is currently the last point for probe to succeed or defer
> (until possibly, as you mentioned, module loading resolves the defer).
> If a probe defers above, it will defer again below.  The set of defers
> should be exactly the same above and below.

Why should it?  Isn't this late_initcall() the first opportunity that
deferred devices get to be re-probed from their first set of attempts
via the drivers having their initcalls called?

If what you're saying is true, what's the point of this late_initcall()?

<re-cut again, I've no idea why you keep adding it back>

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Alternative approach to solve the deferred probe

[Russell King - ARM Linux]

On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote:
> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
> > On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
> >> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> 
> < snip >
> 
> >>> +
> >>>  static bool driver_deferred_probe_enable = false;
> >>> +
> >>>  /**
> >>>   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
> >>>   *
> >>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
> >>>  	driver_deferred_probe_trigger();
> >>
> >> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
> >> not add another round of probes.
> > 
> > The idea is not to report anything for drivers that were deferred
> > during the normal bootup.  The above is part of the normal bootup,
> > and the deferred activity should not be warned about.
> 
> The above is currently the last point for probe to succeed or defer
> (until possibly, as you mentioned, module loading resolves the defer).
> If a probe defers above, it will defer again below.  The set of defers
> should be exactly the same above and below.

Why should it?  Isn't this late_initcall() the first opportunity that
deferred devices get to be re-probed from their first set of attempts
via the drivers having their initcalls called?

If what you're saying is true, what's the point of this late_initcall()?

<re-cut again, I've no idea why you keep adding it back>

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Alternative approach to solve the deferred probe

[Russell King - ARM Linux]

On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote:
> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
> > On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
> >> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> 
> < snip >
> 
> >>> +
> >>>  static bool driver_deferred_probe_enable = false;
> >>> +
> >>>  /**
> >>>   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
> >>>   *
> >>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
> >>>  	driver_deferred_probe_trigger();
> >>
> >> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
> >> not add another round of probes.
> > 
> > The idea is not to report anything for drivers that were deferred
> > during the normal bootup.  The above is part of the normal bootup,
> > and the deferred activity should not be warned about.
> 
> The above is currently the last point for probe to succeed or defer
> (until possibly, as you mentioned, module loading resolves the defer).
> If a probe defers above, it will defer again below.  The set of defers
> should be exactly the same above and below.

Why should it?  Isn't this late_initcall() the first opportunity that
deferred devices get to be re-probed from their first set of attempts
via the drivers having their initcalls called?

If what you're saying is true, what's the point of this late_initcall()?

<re-cut again, I've no idea why you keep adding it back>

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

On Wed, Oct 21, 2015 at 11:18:08AM -0700, Frank Rowand wrote:
> On 10/21/2015 9:27 AM, Mark Brown wrote:

> > Overall boot time and time to get some individual built in component up
> > and running aren't the same thing - what this'll do is get things up
> > more in the link order of the leaf consumers rather than deferring those
> > leaf consumers when their dependencies aren't ready yet.

> Thanks!  I read too much into what was being improved.

> So this patch series, which on other merits may be a good idea, is as
> a by product solving a specific ordering issue, moving successful panel
> initialization to an earlier point in the boot sequence, if I now
> understand more correctly.

Yeah, that's my understanding.

> In that context, this seems like yet another ad hoc way of causing the
> probe order to change in a way to solves one specific issue?  Could
> it just as likely move the boot order of some other driver on some
> other board later, to the detriment of somebody else?

Indeed.  My general feeling is that it does make the link order stuff
more predictable and easier to work with and it does have other merits
(in terms of the error reporting, though there's other ways to address
that like the one Russell is proposing).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

On Wed, Oct 21, 2015 at 11:18:08AM -0700, Frank Rowand wrote:
> On 10/21/2015 9:27 AM, Mark Brown wrote:

> > Overall boot time and time to get some individual built in component up
> > and running aren't the same thing - what this'll do is get things up
> > more in the link order of the leaf consumers rather than deferring those
> > leaf consumers when their dependencies aren't ready yet.

> Thanks!  I read too much into what was being improved.

> So this patch series, which on other merits may be a good idea, is as
> a by product solving a specific ordering issue, moving successful panel
> initialization to an earlier point in the boot sequence, if I now
> understand more correctly.

Yeah, that's my understanding.

> In that context, this seems like yet another ad hoc way of causing the
> probe order to change in a way to solves one specific issue?  Could
> it just as likely move the boot order of some other driver on some
> other board later, to the detriment of somebody else?

Indeed.  My general feeling is that it does make the link order stuff
more predictable and easier to work with and it does have other merits
(in terms of the error reporting, though there's other ways to address
that like the one Russell is proposing).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

On Wed, Oct 21, 2015 at 11:18:08AM -0700, Frank Rowand wrote:
> On 10/21/2015 9:27 AM, Mark Brown wrote:

> > Overall boot time and time to get some individual built in component up
> > and running aren't the same thing - what this'll do is get things up
> > more in the link order of the leaf consumers rather than deferring those
> > leaf consumers when their dependencies aren't ready yet.

> Thanks!  I read too much into what was being improved.

> So this patch series, which on other merits may be a good idea, is as
> a by product solving a specific ordering issue, moving successful panel
> initialization to an earlier point in the boot sequence, if I now
> understand more correctly.

Yeah, that's my understanding.

> In that context, this seems like yet another ad hoc way of causing the
> probe order to change in a way to solves one specific issue?  Could
> it just as likely move the boot order of some other driver on some
> other board later, to the detriment of somebody else?

Indeed.  My general feeling is that it does make the link order stuff
more predictable and easier to work with and it does have other merits
(in terms of the error reporting, though there's other ways to address
that like the one Russell is proposing).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> On 10/21/2015 9:27 AM, Mark Brown wrote:
>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>
>>>> To be clear, I was saying that this series should NOT affect total
>>>> boot times much.
>>
>>> I'm confused.  If I understood correctly, improving boot time was
>>> the key justification for accepting this patch set.  For example,
>>> from "[PATCH v7 0/20] On-demand device probing":
>>>
>>>    I have a problem with the panel on my Tegra Chromebook taking longer
>>>    than expected to be ready during boot (Stéphane Marchesin reported what
>>>    is basically the same issue in [0]), and have looked into ordered
>>>    probing as a better way of solving this than moving nodes around in the
>>>    DT or playing with initcall levels and linking order.
>>>
>>>    ...
>>>
>>>    With this series I get the kernel to output to the panel in 0.5s,
>>>    instead of 2.8s.
>>
>> Overall boot time and time to get some individual built in component up
>> and running aren't the same thing - what this'll do is get things up
>> more in the link order of the leaf consumers rather than deferring those
>> leaf consumers when their dependencies aren't ready yet.
>
> Thanks!  I read too much into what was being improved.
>
> So this patch series, which on other merits may be a good idea, is as
> a by product solving a specific ordering issue, moving successful panel
> initialization to an earlier point in the boot sequence, if I now
> understand more correctly.
>
> In that context, this seems like yet another ad hoc way of causing the
> probe order to change in a way to solves one specific issue?  Could
> it just as likely move the boot order of some other driver on some
> other board later, to the detriment of somebody else?

Time to display on is important for many products. Having the console
up as early as possible is another case. CAN bus is another. This is a
real problem that is not just bad drivers.

I don't think it is completely ad hoc. Given all devices are
registered after drivers, drivers will still probe first in initcall
level order and then link order AFAIK. We may not take (more) initcall
level tweak hacks, but that is a much more simple change for
downstream. Don't get me wrong, I'd really like to see a way to
control order independent of initcall level.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> On 10/21/2015 9:27 AM, Mark Brown wrote:
>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>
>>>> To be clear, I was saying that this series should NOT affect total
>>>> boot times much.
>>
>>> I'm confused.  If I understood correctly, improving boot time was
>>> the key justification for accepting this patch set.  For example,
>>> from "[PATCH v7 0/20] On-demand device probing":
>>>
>>>    I have a problem with the panel on my Tegra Chromebook taking longer
>>>    than expected to be ready during boot (Stéphane Marchesin reported what
>>>    is basically the same issue in [0]), and have looked into ordered
>>>    probing as a better way of solving this than moving nodes around in the
>>>    DT or playing with initcall levels and linking order.
>>>
>>>    ...
>>>
>>>    With this series I get the kernel to output to the panel in 0.5s,
>>>    instead of 2.8s.
>>
>> Overall boot time and time to get some individual built in component up
>> and running aren't the same thing - what this'll do is get things up
>> more in the link order of the leaf consumers rather than deferring those
>> leaf consumers when their dependencies aren't ready yet.
>
> Thanks!  I read too much into what was being improved.
>
> So this patch series, which on other merits may be a good idea, is as
> a by product solving a specific ordering issue, moving successful panel
> initialization to an earlier point in the boot sequence, if I now
> understand more correctly.
>
> In that context, this seems like yet another ad hoc way of causing the
> probe order to change in a way to solves one specific issue?  Could
> it just as likely move the boot order of some other driver on some
> other board later, to the detriment of somebody else?

Time to display on is important for many products. Having the console
up as early as possible is another case. CAN bus is another. This is a
real problem that is not just bad drivers.

I don't think it is completely ad hoc. Given all devices are
registered after drivers, drivers will still probe first in initcall
level order and then link order AFAIK. We may not take (more) initcall
level tweak hacks, but that is a much more simple change for
downstream. Don't get me wrong, I'd really like to see a way to
control order independent of initcall level.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrot=
e:
> On 10/21/2015 9:27 AM, Mark Brown wrote:
>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>
>>>> To be clear, I was saying that this series should NOT affect total
>>>> boot times much.
>>
>>> I'm confused.  If I understood correctly, improving boot time was
>>> the key justification for accepting this patch set.  For example,
>>> from "[PATCH v7 0/20] On-demand device probing":
>>>
>>>    I have a problem with the panel on my Tegra Chromebook taking longer
>>>    than expected to be ready during boot (St=C3=A9phane Marchesin repor=
ted what
>>>    is basically the same issue in [0]), and have looked into ordered
>>>    probing as a better way of solving this than moving nodes around in =
the
>>>    DT or playing with initcall levels and linking order.
>>>
>>>    ...
>>>
>>>    With this series I get the kernel to output to the panel in 0.5s,
>>>    instead of 2.8s.
>>
>> Overall boot time and time to get some individual built in component up
>> and running aren't the same thing - what this'll do is get things up
>> more in the link order of the leaf consumers rather than deferring those
>> leaf consumers when their dependencies aren't ready yet.
>
> Thanks!  I read too much into what was being improved.
>
> So this patch series, which on other merits may be a good idea, is as
> a by product solving a specific ordering issue, moving successful panel
> initialization to an earlier point in the boot sequence, if I now
> understand more correctly.
>
> In that context, this seems like yet another ad hoc way of causing the
> probe order to change in a way to solves one specific issue?  Could
> it just as likely move the boot order of some other driver on some
> other board later, to the detriment of somebody else?

Time to display on is important for many products. Having the console
up as early as possible is another case. CAN bus is another. This is a
real problem that is not just bad drivers.

I don't think it is completely ad hoc. Given all devices are
registered after drivers, drivers will still probe first in initcall
level order and then link order AFAIK. We may not take (more) initcall
level tweak hacks, but that is a much more simple change for
downstream. Don't get me wrong, I'd really like to see a way to
control order independent of initcall level.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> On 10/21/2015 9:27 AM, Mark Brown wrote:
>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>
>>>> To be clear, I was saying that this series should NOT affect total
>>>> boot times much.
>>
>>> I'm confused.  If I understood correctly, improving boot time was
>>> the key justification for accepting this patch set.  For example,
>>> from "[PATCH v7 0/20] On-demand device probing":
>>>
>>>    I have a problem with the panel on my Tegra Chromebook taking longer
>>>    than expected to be ready during boot (Stéphane Marchesin reported what
>>>    is basically the same issue in [0]), and have looked into ordered
>>>    probing as a better way of solving this than moving nodes around in the
>>>    DT or playing with initcall levels and linking order.
>>>
>>>    ...
>>>
>>>    With this series I get the kernel to output to the panel in 0.5s,
>>>    instead of 2.8s.
>>
>> Overall boot time and time to get some individual built in component up
>> and running aren't the same thing - what this'll do is get things up
>> more in the link order of the leaf consumers rather than deferring those
>> leaf consumers when their dependencies aren't ready yet.
>
> Thanks!  I read too much into what was being improved.
>
> So this patch series, which on other merits may be a good idea, is as
> a by product solving a specific ordering issue, moving successful panel
> initialization to an earlier point in the boot sequence, if I now
> understand more correctly.
>
> In that context, this seems like yet another ad hoc way of causing the
> probe order to change in a way to solves one specific issue?  Could
> it just as likely move the boot order of some other driver on some
> other board later, to the detriment of somebody else?

Time to display on is important for many products. Having the console
up as early as possible is another case. CAN bus is another. This is a
real problem that is not just bad drivers.

I don't think it is completely ad hoc. Given all devices are
registered after drivers, drivers will still probe first in initcall
level order and then link order AFAIK. We may not take (more) initcall
level tweak hacks, but that is a much more simple change for
downstream. Don't get me wrong, I'd really like to see a way to
control order independent of initcall level.

Rob

Re: [GIT PULL] On-demand device probing

[Frank Rowand]

On 10/21/2015 2:12 PM, Rob Herring wrote:
> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> On 10/21/2015 9:27 AM, Mark Brown wrote:
>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>>
>>>>> To be clear, I was saying that this series should NOT affect total
>>>>> boot times much.
>>>
>>>> I'm confused.  If I understood correctly, improving boot time was
>>>> the key justification for accepting this patch set.  For example,
>>>> from "[PATCH v7 0/20] On-demand device probing":
>>>>
>>>>    I have a problem with the panel on my Tegra Chromebook taking longer
>>>>    than expected to be ready during boot (Stéphane Marchesin reported what
>>>>    is basically the same issue in [0]), and have looked into ordered
>>>>    probing as a better way of solving this than moving nodes around in the
>>>>    DT or playing with initcall levels and linking order.
>>>>
>>>>    ...
>>>>
>>>>    With this series I get the kernel to output to the panel in 0.5s,
>>>>    instead of 2.8s.
>>>
>>> Overall boot time and time to get some individual built in component up
>>> and running aren't the same thing - what this'll do is get things up
>>> more in the link order of the leaf consumers rather than deferring those
>>> leaf consumers when their dependencies aren't ready yet.
>>
>> Thanks!  I read too much into what was being improved.
>>
>> So this patch series, which on other merits may be a good idea, is as
>> a by product solving a specific ordering issue, moving successful panel
>> initialization to an earlier point in the boot sequence, if I now
>> understand more correctly.
>>
>> In that context, this seems like yet another ad hoc way of causing the
>> probe order to change in a way to solves one specific issue?  Could
>> it just as likely move the boot order of some other driver on some
>> other board later, to the detriment of somebody else?
> 
> Time to display on is important for many products. Having the console
> up as early as possible is another case. CAN bus is another. This is a
> real problem that is not just bad drivers.

Yes, I agree.

What I am seeing is that there continues to be a need for the ability
to explicitly order at least some driver initialization (at some
granularity), despite the push back against explicit ordering that
has been present in the past.


> I don't think it is completely ad hoc. Given all devices are
> registered after drivers, drivers will still probe first in initcall
> level order and then link order AFAIK. We may not take (more) initcall
> level tweak hacks, but that is a much more simple change for
> downstream. Don't get me wrong, I'd really like to see a way to
> control order independent of initcall level.
> 
> Rob

Yep, it is not directly ad hoc, just a fortunate side effect in
this case.  So just accidently ad hoc. :-)

-Frank

Re: [GIT PULL] On-demand device probing

[Frank Rowand]

On 10/21/2015 2:12 PM, Rob Herring wrote:
> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> On 10/21/2015 9:27 AM, Mark Brown wrote:
>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>>
>>>>> To be clear, I was saying that this series should NOT affect total
>>>>> boot times much.
>>>
>>>> I'm confused.  If I understood correctly, improving boot time was
>>>> the key justification for accepting this patch set.  For example,
>>>> from "[PATCH v7 0/20] On-demand device probing":
>>>>
>>>>    I have a problem with the panel on my Tegra Chromebook taking longer
>>>>    than expected to be ready during boot (Stéphane Marchesin reported what
>>>>    is basically the same issue in [0]), and have looked into ordered
>>>>    probing as a better way of solving this than moving nodes around in the
>>>>    DT or playing with initcall levels and linking order.
>>>>
>>>>    ...
>>>>
>>>>    With this series I get the kernel to output to the panel in 0.5s,
>>>>    instead of 2.8s.
>>>
>>> Overall boot time and time to get some individual built in component up
>>> and running aren't the same thing - what this'll do is get things up
>>> more in the link order of the leaf consumers rather than deferring those
>>> leaf consumers when their dependencies aren't ready yet.
>>
>> Thanks!  I read too much into what was being improved.
>>
>> So this patch series, which on other merits may be a good idea, is as
>> a by product solving a specific ordering issue, moving successful panel
>> initialization to an earlier point in the boot sequence, if I now
>> understand more correctly.
>>
>> In that context, this seems like yet another ad hoc way of causing the
>> probe order to change in a way to solves one specific issue?  Could
>> it just as likely move the boot order of some other driver on some
>> other board later, to the detriment of somebody else?
> 
> Time to display on is important for many products. Having the console
> up as early as possible is another case. CAN bus is another. This is a
> real problem that is not just bad drivers.

Yes, I agree.

What I am seeing is that there continues to be a need for the ability
to explicitly order at least some driver initialization (at some
granularity), despite the push back against explicit ordering that
has been present in the past.


> I don't think it is completely ad hoc. Given all devices are
> registered after drivers, drivers will still probe first in initcall
> level order and then link order AFAIK. We may not take (more) initcall
> level tweak hacks, but that is a much more simple change for
> downstream. Don't get me wrong, I'd really like to see a way to
> control order independent of initcall level.
> 
> Rob

Yep, it is not directly ad hoc, just a fortunate side effect in
this case.  So just accidently ad hoc. :-)

-Frank

Re: [GIT PULL] On-demand device probing

[Frank Rowand]

On 10/21/2015 2:12 PM, Rob Herring wrote:
> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>> On 10/21/2015 9:27 AM, Mark Brown wrote:
>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>>
>>>>> To be clear, I was saying that this series should NOT affect total
>>>>> boot times much.
>>>
>>>> I'm confused.  If I understood correctly, improving boot time was
>>>> the key justification for accepting this patch set.  For example,
>>>> from "[PATCH v7 0/20] On-demand device probing":
>>>>
>>>>    I have a problem with the panel on my Tegra Chromebook taking longer
>>>>    than expected to be ready during boot (Stéphane Marchesin reported what
>>>>    is basically the same issue in [0]), and have looked into ordered
>>>>    probing as a better way of solving this than moving nodes around in the
>>>>    DT or playing with initcall levels and linking order.
>>>>
>>>>    ...
>>>>
>>>>    With this series I get the kernel to output to the panel in 0.5s,
>>>>    instead of 2.8s.
>>>
>>> Overall boot time and time to get some individual built in component up
>>> and running aren't the same thing - what this'll do is get things up
>>> more in the link order of the leaf consumers rather than deferring those
>>> leaf consumers when their dependencies aren't ready yet.
>>
>> Thanks!  I read too much into what was being improved.
>>
>> So this patch series, which on other merits may be a good idea, is as
>> a by product solving a specific ordering issue, moving successful panel
>> initialization to an earlier point in the boot sequence, if I now
>> understand more correctly.
>>
>> In that context, this seems like yet another ad hoc way of causing the
>> probe order to change in a way to solves one specific issue?  Could
>> it just as likely move the boot order of some other driver on some
>> other board later, to the detriment of somebody else?
> 
> Time to display on is important for many products. Having the console
> up as early as possible is another case. CAN bus is another. This is a
> real problem that is not just bad drivers.

Yes, I agree.

What I am seeing is that there continues to be a need for the ability
to explicitly order at least some driver initialization (at some
granularity), despite the push back against explicit ordering that
has been present in the past.


> I don't think it is completely ad hoc. Given all devices are
> registered after drivers, drivers will still probe first in initcall
> level order and then link order AFAIK. We may not take (more) initcall
> level tweak hacks, but that is a much more simple change for
> downstream. Don't get me wrong, I'd really like to see a way to
> control order independent of initcall level.
> 
> Rob

Yep, it is not directly ad hoc, just a fortunate side effect in
this case.  So just accidently ad hoc. :-)

-Frank

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Wednesday, October 21, 2015 10:55:14 AM Geert Uytterhoeven wrote:
> Hi Rafael,
> 
> On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> >> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> > ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
> >> > platform devices by default now.
> >>
> >> Okay, I should have grepped for that:
> >> drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev, NULL);
> >> drivers/base/platform.c:        len = acpi_device_modalias(dev, buf,
> >> PAGE_SIZE -1);
> >> drivers/base/platform.c:        rc = acpi_device_uevent_modalias(dev, env);
> >> drivers/base/platform.c:        /* Then try ACPI style match */
> >> drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv))
> >>
> >> These are all cases which have DT version as well, so we're not really
> >> all that different here. There's a few more for DT, but that probably
> >> means you have just not hit the problems we have yet. For example,
> >> what happens if you have an interrupt line in which the controller is
> >> probed after the device connected to the interrupt line? That required
> >> resolving irqs in platform_get_irq rather than using static resources
> >> to support deferred probe.
> >
> > We don't have this particular problem, because the IRQ controllers are
> > enumerated in a special way.
> 
> What does "in a special way" mean? Can you please be more specific?
> 
> Can you have interrupt controllers that depend on clocks, pin controllers,
> and PM domains?

Currently, there's no native way to represent those dependencies in ACPI.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Wednesday, October 21, 2015 10:55:14 AM Geert Uytterhoeven wrote:
> Hi Rafael,
> 
> On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> >> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> > ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
> >> > platform devices by default now.
> >>
> >> Okay, I should have grepped for that:
> >> drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev, NULL);
> >> drivers/base/platform.c:        len = acpi_device_modalias(dev, buf,
> >> PAGE_SIZE -1);
> >> drivers/base/platform.c:        rc = acpi_device_uevent_modalias(dev, env);
> >> drivers/base/platform.c:        /* Then try ACPI style match */
> >> drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv))
> >>
> >> These are all cases which have DT version as well, so we're not really
> >> all that different here. There's a few more for DT, but that probably
> >> means you have just not hit the problems we have yet. For example,
> >> what happens if you have an interrupt line in which the controller is
> >> probed after the device connected to the interrupt line? That required
> >> resolving irqs in platform_get_irq rather than using static resources
> >> to support deferred probe.
> >
> > We don't have this particular problem, because the IRQ controllers are
> > enumerated in a special way.
> 
> What does "in a special way" mean? Can you please be more specific?
> 
> Can you have interrupt controllers that depend on clocks, pin controllers,
> and PM domains?

Currently, there's no native way to represent those dependencies in ACPI.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Wednesday, October 21, 2015 10:55:14 AM Geert Uytterhoeven wrote:
> Hi Rafael,
> 
> On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> >> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >> > ACPI uses platform devices too.  In fact, ACPI device objects are enumerated as
> >> > platform devices by default now.
> >>
> >> Okay, I should have grepped for that:
> >> drivers/base/platform.c:                ACPI_COMPANION_SET(&pdev->dev, NULL);
> >> drivers/base/platform.c:        len = acpi_device_modalias(dev, buf,
> >> PAGE_SIZE -1);
> >> drivers/base/platform.c:        rc = acpi_device_uevent_modalias(dev, env);
> >> drivers/base/platform.c:        /* Then try ACPI style match */
> >> drivers/base/platform.c:        if (acpi_driver_match_device(dev, drv))
> >>
> >> These are all cases which have DT version as well, so we're not really
> >> all that different here. There's a few more for DT, but that probably
> >> means you have just not hit the problems we have yet. For example,
> >> what happens if you have an interrupt line in which the controller is
> >> probed after the device connected to the interrupt line? That required
> >> resolving irqs in platform_get_irq rather than using static resources
> >> to support deferred probe.
> >
> > We don't have this particular problem, because the IRQ controllers are
> > enumerated in a special way.
> 
> What does "in a special way" mean? Can you please be more specific?
> 
> Can you have interrupt controllers that depend on clocks, pin controllers,
> and PM domains?

Currently, there's no native way to represent those dependencies in ACPI.

Thanks,
Rafael

Re: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/21/2015 1:35 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote:
>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>
>> < snip >
>>
>>>>> +
>>>>>  static bool driver_deferred_probe_enable = false;
>>>>> +
>>>>>  /**
>>>>>   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>>   *
>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>>  	driver_deferred_probe_trigger();
>>>>
>>>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>>>> not add another round of probes.
>>>
>>> The idea is not to report anything for drivers that were deferred
>>> during the normal bootup.  The above is part of the normal bootup,
>>> and the deferred activity should not be warned about.
>>
>> The above is currently the last point for probe to succeed or defer
>> (until possibly, as you mentioned, module loading resolves the defer).
>> If a probe defers above, it will defer again below.  The set of defers
>> should be exactly the same above and below.
> 
> Why should it?

My assertion was incorrect.  A probe in the deferral processing can
result in the driver being placed on the new deferred list, then when
a later probe of another deferred driver succeeds, the first driver
will be moved to the active deferred list, and might succeed on
the second probe attempt (or with the current messages would result
in a second set of deferred messages).  So yes, placing
"driver_deferred_probe_report = true" where your patch put it and
running through the deferred probe processing again is correct.

-Frank

Re: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/21/2015 1:35 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote:
>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>
>> < snip >
>>
>>>>> +
>>>>>  static bool driver_deferred_probe_enable = false;
>>>>> +
>>>>>  /**
>>>>>   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>>   *
>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>>  	driver_deferred_probe_trigger();
>>>>
>>>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>>>> not add another round of probes.
>>>
>>> The idea is not to report anything for drivers that were deferred
>>> during the normal bootup.  The above is part of the normal bootup,
>>> and the deferred activity should not be warned about.
>>
>> The above is currently the last point for probe to succeed or defer
>> (until possibly, as you mentioned, module loading resolves the defer).
>> If a probe defers above, it will defer again below.  The set of defers
>> should be exactly the same above and below.
> 
> Why should it?

My assertion was incorrect.  A probe in the deferral processing can
result in the driver being placed on the new deferred list, then when
a later probe of another deferred driver succeeds, the first driver
will be moved to the active deferred list, and might succeed on
the second probe attempt (or with the current messages would result
in a second set of deferred messages).  So yes, placing
"driver_deferred_probe_report = true" where your patch put it and
running through the deferred probe processing again is correct.

-Frank

Re: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/21/2015 1:35 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote:
>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>
>> < snip >
>>
>>>>> +
>>>>>  static bool driver_deferred_probe_enable = false;
>>>>> +
>>>>>  /**
>>>>>   * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>>   *
>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>>  	driver_deferred_probe_trigger();
>>>>
>>>> Couldn't you put the "driver_deferred_probe_report = true" here?  And then
>>>> not add another round of probes.
>>>
>>> The idea is not to report anything for drivers that were deferred
>>> during the normal bootup.  The above is part of the normal bootup,
>>> and the deferred activity should not be warned about.
>>
>> The above is currently the last point for probe to succeed or defer
>> (until possibly, as you mentioned, module loading resolves the defer).
>> If a probe defers above, it will defer again below.  The set of defers
>> should be exactly the same above and below.
> 
> Why should it?

My assertion was incorrect.  A probe in the deferral processing can
result in the driver being placed on the new deferred list, then when
a later probe of another deferred driver succeeds, the first driver
will be moved to the active deferred list, and might succeed on
the second probe attempt (or with the current messages would result
in a second set of deferred messages).  So yes, placing
"driver_deferred_probe_report = true" where your patch put it and
running through the deferred probe processing again is correct.

-Frank

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
> On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Tue, 20 Oct 2015, Mark Brown wrote:
> >
> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >>
> >> > Furthermore, that applies only to devices that use synchronous suspend.
> >> > Async suspend is becoming common, and there the only restrictions are
> >> > parent-child relations plus whatever explicit requirements that drivers
> >> > impose by calling device_pm_wait_for_dev().
> >>
> >> Hrm, this is the first I'd noticed that feature though I see the initial
> >> commit dates from January.
> >
> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
> > not 2015!
> >
> >>  It looks like most of the users are PCs at
> >> the minute but we should be using it more widely for embedded things,
> >> there's definitely some cases I'm aware of where it will allow us to
> >> remove some open coding.
> >>
> >> It does seem like we want to be feeding dependency information we
> >> discover for probing way into the suspend dependencies...
> >
> > Rafael has been thinking about a way to do this systematically.
> > Nothing concrete has emerged yet.
> 
> This iteration of the series would make this quite easy, as
> dependencies are calculated before probes are attempted:
> 
> https://lkml.org/lkml/2015/6/17/311

Well, if you know how to represent "links" between devices, the mechanism
introduced here doesn't really add much value, because in that case the
core knows what the dependencies are in the first place and can only
defer the probes that have to be deferred.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
> On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Tue, 20 Oct 2015, Mark Brown wrote:
> >
> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >>
> >> > Furthermore, that applies only to devices that use synchronous suspend.
> >> > Async suspend is becoming common, and there the only restrictions are
> >> > parent-child relations plus whatever explicit requirements that drivers
> >> > impose by calling device_pm_wait_for_dev().
> >>
> >> Hrm, this is the first I'd noticed that feature though I see the initial
> >> commit dates from January.
> >
> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
> > not 2015!
> >
> >>  It looks like most of the users are PCs at
> >> the minute but we should be using it more widely for embedded things,
> >> there's definitely some cases I'm aware of where it will allow us to
> >> remove some open coding.
> >>
> >> It does seem like we want to be feeding dependency information we
> >> discover for probing way into the suspend dependencies...
> >
> > Rafael has been thinking about a way to do this systematically.
> > Nothing concrete has emerged yet.
> 
> This iteration of the series would make this quite easy, as
> dependencies are calculated before probes are attempted:
> 
> https://lkml.org/lkml/2015/6/17/311

Well, if you know how to represent "links" between devices, the mechanism
introduced here doesn't really add much value, because in that case the
core knows what the dependencies are in the first place and can only
defer the probes that have to be deferred.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
> On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Tue, 20 Oct 2015, Mark Brown wrote:
> >
> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >>
> >> > Furthermore, that applies only to devices that use synchronous suspend.
> >> > Async suspend is becoming common, and there the only restrictions are
> >> > parent-child relations plus whatever explicit requirements that drivers
> >> > impose by calling device_pm_wait_for_dev().
> >>
> >> Hrm, this is the first I'd noticed that feature though I see the initial
> >> commit dates from January.
> >
> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
> > not 2015!
> >
> >>  It looks like most of the users are PCs at
> >> the minute but we should be using it more widely for embedded things,
> >> there's definitely some cases I'm aware of where it will allow us to
> >> remove some open coding.
> >>
> >> It does seem like we want to be feeding dependency information we
> >> discover for probing way into the suspend dependencies...
> >
> > Rafael has been thinking about a way to do this systematically.
> > Nothing concrete has emerged yet.
> 
> This iteration of the series would make this quite easy, as
> dependencies are calculated before probes are attempted:
> 
> https://lkml.org/lkml/2015/6/17/311

Well, if you know how to represent "links" between devices, the mechanism
introduced here doesn't really add much value, because in that case the
core knows what the dependencies are in the first place and can only
defer the probes that have to be deferred.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 21 October 2015 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote:
> On 10/21/2015 2:12 PM, Rob Herring wrote:
>> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>>> On 10/21/2015 9:27 AM, Mark Brown wrote:
>>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>>>
>>>>>> To be clear, I was saying that this series should NOT affect total
>>>>>> boot times much.
>>>>
>>>>> I'm confused.  If I understood correctly, improving boot time was
>>>>> the key justification for accepting this patch set.  For example,
>>>>> from "[PATCH v7 0/20] On-demand device probing":
>>>>>
>>>>>    I have a problem with the panel on my Tegra Chromebook taking longer
>>>>>    than expected to be ready during boot (Stéphane Marchesin reported what
>>>>>    is basically the same issue in [0]), and have looked into ordered
>>>>>    probing as a better way of solving this than moving nodes around in the
>>>>>    DT or playing with initcall levels and linking order.
>>>>>
>>>>>    ...
>>>>>
>>>>>    With this series I get the kernel to output to the panel in 0.5s,
>>>>>    instead of 2.8s.
>>>>
>>>> Overall boot time and time to get some individual built in component up
>>>> and running aren't the same thing - what this'll do is get things up
>>>> more in the link order of the leaf consumers rather than deferring those
>>>> leaf consumers when their dependencies aren't ready yet.
>>>
>>> Thanks!  I read too much into what was being improved.
>>>
>>> So this patch series, which on other merits may be a good idea, is as
>>> a by product solving a specific ordering issue, moving successful panel
>>> initialization to an earlier point in the boot sequence, if I now
>>> understand more correctly.
>>>
>>> In that context, this seems like yet another ad hoc way of causing the
>>> probe order to change in a way to solves one specific issue?  Could
>>> it just as likely move the boot order of some other driver on some
>>> other board later, to the detriment of somebody else?
>>
>> Time to display on is important for many products. Having the console
>> up as early as possible is another case. CAN bus is another. This is a
>> real problem that is not just bad drivers.
>
> Yes, I agree.
>
> What I am seeing is that there continues to be a need for the ability
> to explicitly order at least some driver initialization (at some
> granularity), despite the push back against explicit ordering that
> has been present in the past.

The important point that I have struggled to explain is that right now
for downstreams to influence the order in which devices are probed,
they have to carry a substantial amount of patches that cannot be ever
upstreamed. This fiddling with initcall levels and link order means
changing files that are very frequently changing, increasing the
amount of work when rebasing and increasing the probability of
regressions after a rebase.

This just adds up to other shortcomings of mainline and ends up with
the net result of vendors getting stuck with 3.4 kernels on SoCs that
start production in 2015. Another consequence is that vendors don't
have a chance to upstream their stuff even if they cared. The
overarching goal of the project I'm in is to reduce those shortcomings
that downstreams have to workaround, to facilitate their involvement
upstream.

With this series, the order in which devices are probed becomes the
order in which they were registered, which is the order in which the
devices appear in the FW description of the hw or in the board files
(much more predictable, which makes for a more robust process). For DT
and board files, which cover a good part of the consumer devices
shipped today with Linux, the downstream could just change the order
of device nodes and get their display or whatever to probe before any
other devices.

And even if downstream's hw has a SoC .dtsi that exists in mainline,
they could add a step to their build process that automatically
reorders the nodes to avoid carrying changes to that DT fragment.

But that's moot currently because Greg believes that the time spent
probing devices at boot time could be reduced enough so that the order
in which devices are probed becomes irrelevant. IME that would have to
be under 200ms so that the user doesn't notice and that's unicorn-far
from any bootlog I have ever seen.

Given that downstreams are already carrying as many hacks as they
could think of to speed total boot up, I think this is effectively
telling them to go away.

Sorry for the rant,

Tomeu

>> I don't think it is completely ad hoc. Given all devices are
>> registered after drivers, drivers will still probe first in initcall
>> level order and then link order AFAIK. We may not take (more) initcall
>> level tweak hacks, but that is a much more simple change for
>> downstream. Don't get me wrong, I'd really like to see a way to
>> control order independent of initcall level.
>>
>> Rob
>
> Yep, it is not directly ad hoc, just a fortunate side effect in
> this case.  So just accidently ad hoc. :-)
>
> -Frank
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 21 October 2015 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote:
> On 10/21/2015 2:12 PM, Rob Herring wrote:
>> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>>> On 10/21/2015 9:27 AM, Mark Brown wrote:
>>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>>>
>>>>>> To be clear, I was saying that this series should NOT affect total
>>>>>> boot times much.
>>>>
>>>>> I'm confused.  If I understood correctly, improving boot time was
>>>>> the key justification for accepting this patch set.  For example,
>>>>> from "[PATCH v7 0/20] On-demand device probing":
>>>>>
>>>>>    I have a problem with the panel on my Tegra Chromebook taking longer
>>>>>    than expected to be ready during boot (Stéphane Marchesin reported what
>>>>>    is basically the same issue in [0]), and have looked into ordered
>>>>>    probing as a better way of solving this than moving nodes around in the
>>>>>    DT or playing with initcall levels and linking order.
>>>>>
>>>>>    ...
>>>>>
>>>>>    With this series I get the kernel to output to the panel in 0.5s,
>>>>>    instead of 2.8s.
>>>>
>>>> Overall boot time and time to get some individual built in component up
>>>> and running aren't the same thing - what this'll do is get things up
>>>> more in the link order of the leaf consumers rather than deferring those
>>>> leaf consumers when their dependencies aren't ready yet.
>>>
>>> Thanks!  I read too much into what was being improved.
>>>
>>> So this patch series, which on other merits may be a good idea, is as
>>> a by product solving a specific ordering issue, moving successful panel
>>> initialization to an earlier point in the boot sequence, if I now
>>> understand more correctly.
>>>
>>> In that context, this seems like yet another ad hoc way of causing the
>>> probe order to change in a way to solves one specific issue?  Could
>>> it just as likely move the boot order of some other driver on some
>>> other board later, to the detriment of somebody else?
>>
>> Time to display on is important for many products. Having the console
>> up as early as possible is another case. CAN bus is another. This is a
>> real problem that is not just bad drivers.
>
> Yes, I agree.
>
> What I am seeing is that there continues to be a need for the ability
> to explicitly order at least some driver initialization (at some
> granularity), despite the push back against explicit ordering that
> has been present in the past.

The important point that I have struggled to explain is that right now
for downstreams to influence the order in which devices are probed,
they have to carry a substantial amount of patches that cannot be ever
upstreamed. This fiddling with initcall levels and link order means
changing files that are very frequently changing, increasing the
amount of work when rebasing and increasing the probability of
regressions after a rebase.

This just adds up to other shortcomings of mainline and ends up with
the net result of vendors getting stuck with 3.4 kernels on SoCs that
start production in 2015. Another consequence is that vendors don't
have a chance to upstream their stuff even if they cared. The
overarching goal of the project I'm in is to reduce those shortcomings
that downstreams have to workaround, to facilitate their involvement
upstream.

With this series, the order in which devices are probed becomes the
order in which they were registered, which is the order in which the
devices appear in the FW description of the hw or in the board files
(much more predictable, which makes for a more robust process). For DT
and board files, which cover a good part of the consumer devices
shipped today with Linux, the downstream could just change the order
of device nodes and get their display or whatever to probe before any
other devices.

And even if downstream's hw has a SoC .dtsi that exists in mainline,
they could add a step to their build process that automatically
reorders the nodes to avoid carrying changes to that DT fragment.

But that's moot currently because Greg believes that the time spent
probing devices at boot time could be reduced enough so that the order
in which devices are probed becomes irrelevant. IME that would have to
be under 200ms so that the user doesn't notice and that's unicorn-far
from any bootlog I have ever seen.

Given that downstreams are already carrying as many hacks as they
could think of to speed total boot up, I think this is effectively
telling them to go away.

Sorry for the rant,

Tomeu

>> I don't think it is completely ad hoc. Given all devices are
>> registered after drivers, drivers will still probe first in initcall
>> level order and then link order AFAIK. We may not take (more) initcall
>> level tweak hacks, but that is a much more simple change for
>> downstream. Don't get me wrong, I'd really like to see a way to
>> control order independent of initcall level.
>>
>> Rob
>
> Yep, it is not directly ad hoc, just a fortunate side effect in
> this case.  So just accidently ad hoc. :-)
>
> -Frank
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 21 October 2015 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote:
> On 10/21/2015 2:12 PM, Rob Herring wrote:
>> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> w=
rote:
>>> On 10/21/2015 9:27 AM, Mark Brown wrote:
>>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>>>
>>>>>> To be clear, I was saying that this series should NOT affect total
>>>>>> boot times much.
>>>>
>>>>> I'm confused.  If I understood correctly, improving boot time was
>>>>> the key justification for accepting this patch set.  For example,
>>>>> from "[PATCH v7 0/20] On-demand device probing":
>>>>>
>>>>>    I have a problem with the panel on my Tegra Chromebook taking long=
er
>>>>>    than expected to be ready during boot (St=C3=A9phane Marchesin rep=
orted what
>>>>>    is basically the same issue in [0]), and have looked into ordered
>>>>>    probing as a better way of solving this than moving nodes around i=
n the
>>>>>    DT or playing with initcall levels and linking order.
>>>>>
>>>>>    ...
>>>>>
>>>>>    With this series I get the kernel to output to the panel in 0.5s,
>>>>>    instead of 2.8s.
>>>>
>>>> Overall boot time and time to get some individual built in component u=
p
>>>> and running aren't the same thing - what this'll do is get things up
>>>> more in the link order of the leaf consumers rather than deferring tho=
se
>>>> leaf consumers when their dependencies aren't ready yet.
>>>
>>> Thanks!  I read too much into what was being improved.
>>>
>>> So this patch series, which on other merits may be a good idea, is as
>>> a by product solving a specific ordering issue, moving successful panel
>>> initialization to an earlier point in the boot sequence, if I now
>>> understand more correctly.
>>>
>>> In that context, this seems like yet another ad hoc way of causing the
>>> probe order to change in a way to solves one specific issue?  Could
>>> it just as likely move the boot order of some other driver on some
>>> other board later, to the detriment of somebody else?
>>
>> Time to display on is important for many products. Having the console
>> up as early as possible is another case. CAN bus is another. This is a
>> real problem that is not just bad drivers.
>
> Yes, I agree.
>
> What I am seeing is that there continues to be a need for the ability
> to explicitly order at least some driver initialization (at some
> granularity), despite the push back against explicit ordering that
> has been present in the past.

The important point that I have struggled to explain is that right now
for downstreams to influence the order in which devices are probed,
they have to carry a substantial amount of patches that cannot be ever
upstreamed. This fiddling with initcall levels and link order means
changing files that are very frequently changing, increasing the
amount of work when rebasing and increasing the probability of
regressions after a rebase.

This just adds up to other shortcomings of mainline and ends up with
the net result of vendors getting stuck with 3.4 kernels on SoCs that
start production in 2015. Another consequence is that vendors don't
have a chance to upstream their stuff even if they cared. The
overarching goal of the project I'm in is to reduce those shortcomings
that downstreams have to workaround, to facilitate their involvement
upstream.

With this series, the order in which devices are probed becomes the
order in which they were registered, which is the order in which the
devices appear in the FW description of the hw or in the board files
(much more predictable, which makes for a more robust process). For DT
and board files, which cover a good part of the consumer devices
shipped today with Linux, the downstream could just change the order
of device nodes and get their display or whatever to probe before any
other devices.

And even if downstream's hw has a SoC .dtsi that exists in mainline,
they could add a step to their build process that automatically
reorders the nodes to avoid carrying changes to that DT fragment.

But that's moot currently because Greg believes that the time spent
probing devices at boot time could be reduced enough so that the order
in which devices are probed becomes irrelevant. IME that would have to
be under 200ms so that the user doesn't notice and that's unicorn-far
from any bootlog I have ever seen.

Given that downstreams are already carrying as many hacks as they
could think of to speed total boot up, I think this is effectively
telling them to go away.

Sorry for the rant,

Tomeu

>> I don't think it is completely ad hoc. Given all devices are
>> registered after drivers, drivers will still probe first in initcall
>> level order and then link order AFAIK. We may not take (more) initcall
>> level tweak hacks, but that is a much more simple change for
>> downstream. Don't get me wrong, I'd really like to see a way to
>> control order independent of initcall level.
>>
>> Rob
>
> Yep, it is not directly ad hoc, just a fortunate side effect in
> this case.  So just accidently ad hoc. :-)
>
> -Frank
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
n
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 21 October 2015 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote:
> On 10/21/2015 2:12 PM, Rob Herring wrote:
>> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
>>> On 10/21/2015 9:27 AM, Mark Brown wrote:
>>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
>>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
>>>>
>>>>>> To be clear, I was saying that this series should NOT affect total
>>>>>> boot times much.
>>>>
>>>>> I'm confused.  If I understood correctly, improving boot time was
>>>>> the key justification for accepting this patch set.  For example,
>>>>> from "[PATCH v7 0/20] On-demand device probing":
>>>>>
>>>>>    I have a problem with the panel on my Tegra Chromebook taking longer
>>>>>    than expected to be ready during boot (Stéphane Marchesin reported what
>>>>>    is basically the same issue in [0]), and have looked into ordered
>>>>>    probing as a better way of solving this than moving nodes around in the
>>>>>    DT or playing with initcall levels and linking order.
>>>>>
>>>>>    ...
>>>>>
>>>>>    With this series I get the kernel to output to the panel in 0.5s,
>>>>>    instead of 2.8s.
>>>>
>>>> Overall boot time and time to get some individual built in component up
>>>> and running aren't the same thing - what this'll do is get things up
>>>> more in the link order of the leaf consumers rather than deferring those
>>>> leaf consumers when their dependencies aren't ready yet.
>>>
>>> Thanks!  I read too much into what was being improved.
>>>
>>> So this patch series, which on other merits may be a good idea, is as
>>> a by product solving a specific ordering issue, moving successful panel
>>> initialization to an earlier point in the boot sequence, if I now
>>> understand more correctly.
>>>
>>> In that context, this seems like yet another ad hoc way of causing the
>>> probe order to change in a way to solves one specific issue?  Could
>>> it just as likely move the boot order of some other driver on some
>>> other board later, to the detriment of somebody else?
>>
>> Time to display on is important for many products. Having the console
>> up as early as possible is another case. CAN bus is another. This is a
>> real problem that is not just bad drivers.
>
> Yes, I agree.
>
> What I am seeing is that there continues to be a need for the ability
> to explicitly order at least some driver initialization (at some
> granularity), despite the push back against explicit ordering that
> has been present in the past.

The important point that I have struggled to explain is that right now
for downstreams to influence the order in which devices are probed,
they have to carry a substantial amount of patches that cannot be ever
upstreamed. This fiddling with initcall levels and link order means
changing files that are very frequently changing, increasing the
amount of work when rebasing and increasing the probability of
regressions after a rebase.

This just adds up to other shortcomings of mainline and ends up with
the net result of vendors getting stuck with 3.4 kernels on SoCs that
start production in 2015. Another consequence is that vendors don't
have a chance to upstream their stuff even if they cared. The
overarching goal of the project I'm in is to reduce those shortcomings
that downstreams have to workaround, to facilitate their involvement
upstream.

With this series, the order in which devices are probed becomes the
order in which they were registered, which is the order in which the
devices appear in the FW description of the hw or in the board files
(much more predictable, which makes for a more robust process). For DT
and board files, which cover a good part of the consumer devices
shipped today with Linux, the downstream could just change the order
of device nodes and get their display or whatever to probe before any
other devices.

And even if downstream's hw has a SoC .dtsi that exists in mainline,
they could add a step to their build process that automatically
reorders the nodes to avoid carrying changes to that DT fragment.

But that's moot currently because Greg believes that the time spent
probing devices at boot time could be reduced enough so that the order
in which devices are probed becomes irrelevant. IME that would have to
be under 200ms so that the user doesn't notice and that's unicorn-far
from any bootlog I have ever seen.

Given that downstreams are already carrying as many hacks as they
could think of to speed total boot up, I think this is effectively
telling them to go away.

Sorry for the rant,

Tomeu

>> I don't think it is completely ad hoc. Given all devices are
>> registered after drivers, drivers will still probe first in initcall
>> level order and then link order AFAIK. We may not take (more) initcall
>> level tweak hacks, but that is a much more simple change for
>> downstream. Don't get me wrong, I'd really like to see a way to
>> control order independent of initcall level.
>>
>> Rob
>
> Yep, it is not directly ad hoc, just a fortunate side effect in
> this case.  So just accidently ad hoc. :-)
>
> -Frank
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 22 October 2015 at 02:54, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
>> On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> wrote:
>> > On Tue, 20 Oct 2015, Mark Brown wrote:
>> >
>> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>> >>
>> >> > Furthermore, that applies only to devices that use synchronous suspend.
>> >> > Async suspend is becoming common, and there the only restrictions are
>> >> > parent-child relations plus whatever explicit requirements that drivers
>> >> > impose by calling device_pm_wait_for_dev().
>> >>
>> >> Hrm, this is the first I'd noticed that feature though I see the initial
>> >> commit dates from January.
>> >
>> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
>> > not 2015!
>> >
>> >>  It looks like most of the users are PCs at
>> >> the minute but we should be using it more widely for embedded things,
>> >> there's definitely some cases I'm aware of where it will allow us to
>> >> remove some open coding.
>> >>
>> >> It does seem like we want to be feeding dependency information we
>> >> discover for probing way into the suspend dependencies...
>> >
>> > Rafael has been thinking about a way to do this systematically.
>> > Nothing concrete has emerged yet.
>>
>> This iteration of the series would make this quite easy, as
>> dependencies are calculated before probes are attempted:
>>
>> https://lkml.org/lkml/2015/6/17/311
>
> Well, if you know how to represent "links" between devices, the mechanism
> introduced here doesn't really add much value, because in that case the
> core knows what the dependencies are in the first place and can only
> defer the probes that have to be deferred.

By "here" you mean what you are proposing for ordering device
suspends, or on-demand probing?

If you meant that probing on-demand is unneeded if we already have
dependency information, I agree with you and that's why I only pushed
forward on-demand, as the approach linked above introduced some
duplication when inferring the dependencies. Maybe that could be
avoided without too much refactoring.

In any case, Thierry mentioned the other day in #tegra that one could
also collect dependency information as a follow up to the on-demand
series by calling device_depend() or such instead of
of_device_probe().

Regards,

Tomeu

> Thanks,
> Rafael
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 22 October 2015 at 02:54, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
>> On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> wrote:
>> > On Tue, 20 Oct 2015, Mark Brown wrote:
>> >
>> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>> >>
>> >> > Furthermore, that applies only to devices that use synchronous suspend.
>> >> > Async suspend is becoming common, and there the only restrictions are
>> >> > parent-child relations plus whatever explicit requirements that drivers
>> >> > impose by calling device_pm_wait_for_dev().
>> >>
>> >> Hrm, this is the first I'd noticed that feature though I see the initial
>> >> commit dates from January.
>> >
>> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
>> > not 2015!
>> >
>> >>  It looks like most of the users are PCs at
>> >> the minute but we should be using it more widely for embedded things,
>> >> there's definitely some cases I'm aware of where it will allow us to
>> >> remove some open coding.
>> >>
>> >> It does seem like we want to be feeding dependency information we
>> >> discover for probing way into the suspend dependencies...
>> >
>> > Rafael has been thinking about a way to do this systematically.
>> > Nothing concrete has emerged yet.
>>
>> This iteration of the series would make this quite easy, as
>> dependencies are calculated before probes are attempted:
>>
>> https://lkml.org/lkml/2015/6/17/311
>
> Well, if you know how to represent "links" between devices, the mechanism
> introduced here doesn't really add much value, because in that case the
> core knows what the dependencies are in the first place and can only
> defer the probes that have to be deferred.

By "here" you mean what you are proposing for ordering device
suspends, or on-demand probing?

If you meant that probing on-demand is unneeded if we already have
dependency information, I agree with you and that's why I only pushed
forward on-demand, as the approach linked above introduced some
duplication when inferring the dependencies. Maybe that could be
avoided without too much refactoring.

In any case, Thierry mentioned the other day in #tegra that one could
also collect dependency information as a follow up to the on-demand
series by calling device_depend() or such instead of
of_device_probe().

Regards,

Tomeu

> Thanks,
> Rafael
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 22 October 2015 at 02:54, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
>> On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> wrote:
>> > On Tue, 20 Oct 2015, Mark Brown wrote:
>> >
>> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>> >>
>> >> > Furthermore, that applies only to devices that use synchronous suspend.
>> >> > Async suspend is becoming common, and there the only restrictions are
>> >> > parent-child relations plus whatever explicit requirements that drivers
>> >> > impose by calling device_pm_wait_for_dev().
>> >>
>> >> Hrm, this is the first I'd noticed that feature though I see the initial
>> >> commit dates from January.
>> >
>> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
>> > not 2015!
>> >
>> >>  It looks like most of the users are PCs at
>> >> the minute but we should be using it more widely for embedded things,
>> >> there's definitely some cases I'm aware of where it will allow us to
>> >> remove some open coding.
>> >>
>> >> It does seem like we want to be feeding dependency information we
>> >> discover for probing way into the suspend dependencies...
>> >
>> > Rafael has been thinking about a way to do this systematically.
>> > Nothing concrete has emerged yet.
>>
>> This iteration of the series would make this quite easy, as
>> dependencies are calculated before probes are attempted:
>>
>> https://lkml.org/lkml/2015/6/17/311
>
> Well, if you know how to represent "links" between devices, the mechanism
> introduced here doesn't really add much value, because in that case the
> core knows what the dependencies are in the first place and can only
> defer the probes that have to be deferred.

By "here" you mean what you are proposing for ordering device
suspends, or on-demand probing?

If you meant that probing on-demand is unneeded if we already have
dependency information, I agree with you and that's why I only pushed
forward on-demand, as the approach linked above introduced some
duplication when inferring the dependencies. Maybe that could be
avoided without too much refactoring.

In any case, Thierry mentioned the other day in #tegra that one could
also collect dependency information as a follow up to the on-demand
series by calling device_depend() or such instead of
of_device_probe().

Regards,

Tomeu

> Thanks,
> Rafael
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On Tue, Oct 20, 2015 at 04:46:56PM +0100, Russell King - ARM Linux wrote:

> Something like this.  I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
> be fwnode?)  See the commented out of_warn_deferred() in
> drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
> for resources should make debugging why things are getting deferred easier.

Yeah, plus I'd expect it to also result in better error reporting
overall if the subsystems are able to report when they fail to get
something rather than just returning an error to the driver.

> +/**
> + * dev_warn_deferred() - report why a probe has been deferred
> + */
> +void dev_warn_deferred(struct device *dev, const char *fmt, ...)
> +{
> +	if (driver_deferred_probe_report) {
> +		struct va_format vaf;
> +		va_list ap;
> +
> +		va_start(ap, fmt);
> +		vaf.fmt = fmt;
> +		vaf.va = ≈
> +
> +		dev_warn(dev, "deferring probe: %pV", &vaf);
> +		va_end(ap);
> +	}
> +}
> +EXPORT_SYMBOL_GPL(dev_warn_deferred);

I'm not currently able to think of a nice way of writing this but I think
what I'd really like to see from a driver point of view is something
which decays into dev_err() if it's a non-deferral error.  That way
drivers can have minimal log and return error handling code and we will
still get the output sensibly.  The best I can think of is something
like

   void dev_warn_deferred(struct device *dev, int err, const char *fmt, ...)

which requires the caller to pass in err twice to get it logged.  That's
not a thing of beauty but it gets the job done...  but perhaps your
original interface is better, it's a bit cleaner.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On Tue, Oct 20, 2015 at 04:46:56PM +0100, Russell King - ARM Linux wrote:

> Something like this.  I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
> be fwnode?)  See the commented out of_warn_deferred() in
> drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
> for resources should make debugging why things are getting deferred easier.

Yeah, plus I'd expect it to also result in better error reporting
overall if the subsystems are able to report when they fail to get
something rather than just returning an error to the driver.

> +/**
> + * dev_warn_deferred() - report why a probe has been deferred
> + */
> +void dev_warn_deferred(struct device *dev, const char *fmt, ...)
> +{
> +	if (driver_deferred_probe_report) {
> +		struct va_format vaf;
> +		va_list ap;
> +
> +		va_start(ap, fmt);
> +		vaf.fmt = fmt;
> +		vaf.va = ≈
> +
> +		dev_warn(dev, "deferring probe: %pV", &vaf);
> +		va_end(ap);
> +	}
> +}
> +EXPORT_SYMBOL_GPL(dev_warn_deferred);

I'm not currently able to think of a nice way of writing this but I think
what I'd really like to see from a driver point of view is something
which decays into dev_err() if it's a non-deferral error.  That way
drivers can have minimal log and return error handling code and we will
still get the output sensibly.  The best I can think of is something
like

   void dev_warn_deferred(struct device *dev, int err, const char *fmt, ...)

which requires the caller to pass in err twice to get it logged.  That's
not a thing of beauty but it gets the job done...  but perhaps your
original interface is better, it's a bit cleaner.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On Tue, Oct 20, 2015 at 04:46:56PM +0100, Russell King - ARM Linux wrote:

> Something like this.  I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
> be fwnode?)  See the commented out of_warn_deferred() in
> drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
> for resources should make debugging why things are getting deferred easier.

Yeah, plus I'd expect it to also result in better error reporting
overall if the subsystems are able to report when they fail to get
something rather than just returning an error to the driver.

> +/**
> + * dev_warn_deferred() - report why a probe has been deferred
> + */
> +void dev_warn_deferred(struct device *dev, const char *fmt, ...)
> +{
> +	if (driver_deferred_probe_report) {
> +		struct va_format vaf;
> +		va_list ap;
> +
> +		va_start(ap, fmt);
> +		vaf.fmt = fmt;
> +		vaf.va = ≈
> +
> +		dev_warn(dev, "deferring probe: %pV", &vaf);
> +		va_end(ap);
> +	}
> +}
> +EXPORT_SYMBOL_GPL(dev_warn_deferred);

I'm not currently able to think of a nice way of writing this but I think
what I'd really like to see from a driver point of view is something
which decays into dev_err() if it's a non-deferral error.  That way
drivers can have minimal log and return error handling code and we will
still get the output sensibly.  The best I can think of is something
like

   void dev_warn_deferred(struct device *dev, int err, const char *fmt, ...)

which requires the caller to pass in err twice to get it logged.  That's
not a thing of beauty but it gets the job done...  but perhaps your
original interface is better, it's a bit cleaner.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> On 21 October 2015 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote:
> > On 10/21/2015 2:12 PM, Rob Herring wrote:
> >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> >>> On 10/21/2015 9:27 AM, Mark Brown wrote:
> >>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
> >>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> >>>>
> >>>>>> To be clear, I was saying that this series should NOT affect total
> >>>>>> boot times much.
> >>>>
> >>>>> I'm confused.  If I understood correctly, improving boot time was
> >>>>> the key justification for accepting this patch set.  For example,
> >>>>> from "[PATCH v7 0/20] On-demand device probing":
> >>>>>
> >>>>>    I have a problem with the panel on my Tegra Chromebook taking longer
> >>>>>    than expected to be ready during boot (Stéphane Marchesin reported what
> >>>>>    is basically the same issue in [0]), and have looked into ordered
> >>>>>    probing as a better way of solving this than moving nodes around in the
> >>>>>    DT or playing with initcall levels and linking order.
> >>>>>
> >>>>>    ...
> >>>>>
> >>>>>    With this series I get the kernel to output to the panel in 0.5s,
> >>>>>    instead of 2.8s.
> >>>>
> >>>> Overall boot time and time to get some individual built in component up
> >>>> and running aren't the same thing - what this'll do is get things up
> >>>> more in the link order of the leaf consumers rather than deferring those
> >>>> leaf consumers when their dependencies aren't ready yet.
> >>>
> >>> Thanks!  I read too much into what was being improved.
> >>>
> >>> So this patch series, which on other merits may be a good idea, is as
> >>> a by product solving a specific ordering issue, moving successful panel
> >>> initialization to an earlier point in the boot sequence, if I now
> >>> understand more correctly.
> >>>
> >>> In that context, this seems like yet another ad hoc way of causing the
> >>> probe order to change in a way to solves one specific issue?  Could
> >>> it just as likely move the boot order of some other driver on some
> >>> other board later, to the detriment of somebody else?
> >>
> >> Time to display on is important for many products. Having the console
> >> up as early as possible is another case. CAN bus is another. This is a
> >> real problem that is not just bad drivers.
> >
> > Yes, I agree.
> >
> > What I am seeing is that there continues to be a need for the ability
> > to explicitly order at least some driver initialization (at some
> > granularity), despite the push back against explicit ordering that
> > has been present in the past.
> 
> The important point that I have struggled to explain is that right now
> for downstreams to influence the order in which devices are probed,
> they have to carry a substantial amount of patches that cannot be ever
> upstreamed. This fiddling with initcall levels and link order means
> changing files that are very frequently changing, increasing the
> amount of work when rebasing and increasing the probability of
> regressions after a rebase.
> 
> This just adds up to other shortcomings of mainline and ends up with
> the net result of vendors getting stuck with 3.4 kernels on SoCs that
> start production in 2015. Another consequence is that vendors don't
> have a chance to upstream their stuff even if they cared. The
> overarching goal of the project I'm in is to reduce those shortcomings
> that downstreams have to workaround, to facilitate their involvement
> upstream.

The init order of drivers has no influence at all on the ability for
companies to have their individual drivers merged upstream, please don't
be so dramatic about this.

Worst case, a vendor keeps a single patch to drivers/Makefile in their
tree that reorders things, yes it will get conflicts on every release,
but really, it's trivial to maintain if they wish to keep doing this
type of thing.

Again, it is _not_ the reason that we are living with 2million+ lines of
code in vendor kernels.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> On 21 October 2015 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote:
> > On 10/21/2015 2:12 PM, Rob Herring wrote:
> >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> >>> On 10/21/2015 9:27 AM, Mark Brown wrote:
> >>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
> >>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> >>>>
> >>>>>> To be clear, I was saying that this series should NOT affect total
> >>>>>> boot times much.
> >>>>
> >>>>> I'm confused.  If I understood correctly, improving boot time was
> >>>>> the key justification for accepting this patch set.  For example,
> >>>>> from "[PATCH v7 0/20] On-demand device probing":
> >>>>>
> >>>>>    I have a problem with the panel on my Tegra Chromebook taking longer
> >>>>>    than expected to be ready during boot (Stéphane Marchesin reported what
> >>>>>    is basically the same issue in [0]), and have looked into ordered
> >>>>>    probing as a better way of solving this than moving nodes around in the
> >>>>>    DT or playing with initcall levels and linking order.
> >>>>>
> >>>>>    ...
> >>>>>
> >>>>>    With this series I get the kernel to output to the panel in 0.5s,
> >>>>>    instead of 2.8s.
> >>>>
> >>>> Overall boot time and time to get some individual built in component up
> >>>> and running aren't the same thing - what this'll do is get things up
> >>>> more in the link order of the leaf consumers rather than deferring those
> >>>> leaf consumers when their dependencies aren't ready yet.
> >>>
> >>> Thanks!  I read too much into what was being improved.
> >>>
> >>> So this patch series, which on other merits may be a good idea, is as
> >>> a by product solving a specific ordering issue, moving successful panel
> >>> initialization to an earlier point in the boot sequence, if I now
> >>> understand more correctly.
> >>>
> >>> In that context, this seems like yet another ad hoc way of causing the
> >>> probe order to change in a way to solves one specific issue?  Could
> >>> it just as likely move the boot order of some other driver on some
> >>> other board later, to the detriment of somebody else?
> >>
> >> Time to display on is important for many products. Having the console
> >> up as early as possible is another case. CAN bus is another. This is a
> >> real problem that is not just bad drivers.
> >
> > Yes, I agree.
> >
> > What I am seeing is that there continues to be a need for the ability
> > to explicitly order at least some driver initialization (at some
> > granularity), despite the push back against explicit ordering that
> > has been present in the past.
> 
> The important point that I have struggled to explain is that right now
> for downstreams to influence the order in which devices are probed,
> they have to carry a substantial amount of patches that cannot be ever
> upstreamed. This fiddling with initcall levels and link order means
> changing files that are very frequently changing, increasing the
> amount of work when rebasing and increasing the probability of
> regressions after a rebase.
> 
> This just adds up to other shortcomings of mainline and ends up with
> the net result of vendors getting stuck with 3.4 kernels on SoCs that
> start production in 2015. Another consequence is that vendors don't
> have a chance to upstream their stuff even if they cared. The
> overarching goal of the project I'm in is to reduce those shortcomings
> that downstreams have to workaround, to facilitate their involvement
> upstream.

The init order of drivers has no influence at all on the ability for
companies to have their individual drivers merged upstream, please don't
be so dramatic about this.

Worst case, a vendor keeps a single patch to drivers/Makefile in their
tree that reorders things, yes it will get conflicts on every release,
but really, it's trivial to maintain if they wish to keep doing this
type of thing.

Again, it is _not_ the reason that we are living with 2million+ lines of
code in vendor kernels.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> On 21 October 2015 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote:
> > On 10/21/2015 2:12 PM, Rob Herring wrote:
> >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> >>> On 10/21/2015 9:27 AM, Mark Brown wrote:
> >>>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
> >>>>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> >>>>
> >>>>>> To be clear, I was saying that this series should NOT affect total
> >>>>>> boot times much.
> >>>>
> >>>>> I'm confused.  If I understood correctly, improving boot time was
> >>>>> the key justification for accepting this patch set.  For example,
> >>>>> from "[PATCH v7 0/20] On-demand device probing":
> >>>>>
> >>>>>    I have a problem with the panel on my Tegra Chromebook taking longer
> >>>>>    than expected to be ready during boot (Stéphane Marchesin reported what
> >>>>>    is basically the same issue in [0]), and have looked into ordered
> >>>>>    probing as a better way of solving this than moving nodes around in the
> >>>>>    DT or playing with initcall levels and linking order.
> >>>>>
> >>>>>    ...
> >>>>>
> >>>>>    With this series I get the kernel to output to the panel in 0.5s,
> >>>>>    instead of 2.8s.
> >>>>
> >>>> Overall boot time and time to get some individual built in component up
> >>>> and running aren't the same thing - what this'll do is get things up
> >>>> more in the link order of the leaf consumers rather than deferring those
> >>>> leaf consumers when their dependencies aren't ready yet.
> >>>
> >>> Thanks!  I read too much into what was being improved.
> >>>
> >>> So this patch series, which on other merits may be a good idea, is as
> >>> a by product solving a specific ordering issue, moving successful panel
> >>> initialization to an earlier point in the boot sequence, if I now
> >>> understand more correctly.
> >>>
> >>> In that context, this seems like yet another ad hoc way of causing the
> >>> probe order to change in a way to solves one specific issue?  Could
> >>> it just as likely move the boot order of some other driver on some
> >>> other board later, to the detriment of somebody else?
> >>
> >> Time to display on is important for many products. Having the console
> >> up as early as possible is another case. CAN bus is another. This is a
> >> real problem that is not just bad drivers.
> >
> > Yes, I agree.
> >
> > What I am seeing is that there continues to be a need for the ability
> > to explicitly order at least some driver initialization (at some
> > granularity), despite the push back against explicit ordering that
> > has been present in the past.
> 
> The important point that I have struggled to explain is that right now
> for downstreams to influence the order in which devices are probed,
> they have to carry a substantial amount of patches that cannot be ever
> upstreamed. This fiddling with initcall levels and link order means
> changing files that are very frequently changing, increasing the
> amount of work when rebasing and increasing the probability of
> regressions after a rebase.
> 
> This just adds up to other shortcomings of mainline and ends up with
> the net result of vendors getting stuck with 3.4 kernels on SoCs that
> start production in 2015. Another consequence is that vendors don't
> have a chance to upstream their stuff even if they cared. The
> overarching goal of the project I'm in is to reduce those shortcomings
> that downstreams have to workaround, to facilitate their involvement
> upstream.

The init order of drivers has no influence at all on the ability for
companies to have their individual drivers merged upstream, please don't
be so dramatic about this.

Worst case, a vendor keeps a single patch to drivers/Makefile in their
tree that reorders things, yes it will get conflicts on every release,
but really, it's trivial to maintain if they wish to keep doing this
type of thing.

Again, it is _not_ the reason that we are living with 2million+ lines of
code in vendor kernels.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

<oops, sent too early...>

On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> But that's moot currently because Greg believes that the time spent
> probing devices at boot time could be reduced enough so that the order
> in which devices are probed becomes irrelevant. IME that would have to
> be under 200ms so that the user doesn't notice and that's unicorn-far
> from any bootlog I have ever seen.

But as no one has actually produced a bootlog, how do you know that?
Where exactly is your time being spent?  What driver is causing long
delays?  Why is the long-delay-drivers not being done in their own
thread?  And most importantly, why are you ignoring the work that people
did back in 2008 to solve the issue on other hardware platforms?

> Given that downstreams are already carrying as many hacks as they
> could think of to speed total boot up, I think this is effectively
> telling them to go away.

No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
solve-the-random-issue-i'm-having type patch by putting random calls in
semi-random subsystems all over the kernel.

And when I ask for real data, you respond with the fact that you aren't
trying to speed up boot time here at all, so what am I supposed to think
other than that you don't care enough to do the real work and are trying
to hack the driver core up instead.

> Sorry for the rant,

No apologies needed, it's cathartic at times :)

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

<oops, sent too early...>

On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> But that's moot currently because Greg believes that the time spent
> probing devices at boot time could be reduced enough so that the order
> in which devices are probed becomes irrelevant. IME that would have to
> be under 200ms so that the user doesn't notice and that's unicorn-far
> from any bootlog I have ever seen.

But as no one has actually produced a bootlog, how do you know that?
Where exactly is your time being spent?  What driver is causing long
delays?  Why is the long-delay-drivers not being done in their own
thread?  And most importantly, why are you ignoring the work that people
did back in 2008 to solve the issue on other hardware platforms?

> Given that downstreams are already carrying as many hacks as they
> could think of to speed total boot up, I think this is effectively
> telling them to go away.

No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
solve-the-random-issue-i'm-having type patch by putting random calls in
semi-random subsystems all over the kernel.

And when I ask for real data, you respond with the fact that you aren't
trying to speed up boot time here at all, so what am I supposed to think
other than that you don't care enough to do the real work and are trying
to hack the driver core up instead.

> Sorry for the rant,

No apologies needed, it's cathartic at times :)

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

<oops, sent too early...>

On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> But that's moot currently because Greg believes that the time spent
> probing devices at boot time could be reduced enough so that the order
> in which devices are probed becomes irrelevant. IME that would have to
> be under 200ms so that the user doesn't notice and that's unicorn-far
> from any bootlog I have ever seen.

But as no one has actually produced a bootlog, how do you know that?
Where exactly is your time being spent?  What driver is causing long
delays?  Why is the long-delay-drivers not being done in their own
thread?  And most importantly, why are you ignoring the work that people
did back in 2008 to solve the issue on other hardware platforms?

> Given that downstreams are already carrying as many hacks as they
> could think of to speed total boot up, I think this is effectively
> telling them to go away.

No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
solve-the-random-issue-i'm-having type patch by putting random calls in
semi-random subsystems all over the kernel.

And when I ask for real data, you respond with the fact that you aren't
trying to speed up boot time here at all, so what am I supposed to think
other than that you don't care enough to do the real work and are trying
to hack the driver core up instead.

> Sorry for the rant,

No apologies needed, it's cathartic at times :)

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote:
> <oops, sent too early...>
> 
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> > Given that downstreams are already carrying as many hacks as they
> > could think of to speed total boot up, I think this is effectively
> > telling them to go away.
> 
> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> solve-the-random-issue-i'm-having type patch by putting random calls in
> semi-random subsystems all over the kernel.

+100000000000, fully agree.

There's too much verbal diarrhoea going on in this thread and no facts.
I've been waiting for real data too, and there's not one shred of it, or
even a hint that it might appear.  So, the conclusion I'm coming to is
that there isn't any data to back up the claims made in this thread.

If it was such a problem, then in the _eight_ days that this has been
discussed so far, _someone_ would have sent some data showing the
problem.  I think the fact is, there is no data.

Someone prove me wrong.  Someone post the verifiable data showing that
there is a problem to be solved here.

Someone show what the specific failure cases are that are hampering
vendors moving forwards.  Someone show the long boot times by way of
kernel message log.  Someone show some evidence of the problems that
have been alluded to.

If no one can show some evidence, there isn't a problem here. :)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote:
> <oops, sent too early...>
> 
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> > Given that downstreams are already carrying as many hacks as they
> > could think of to speed total boot up, I think this is effectively
> > telling them to go away.
> 
> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> solve-the-random-issue-i'm-having type patch by putting random calls in
> semi-random subsystems all over the kernel.

+100000000000, fully agree.

There's too much verbal diarrhoea going on in this thread and no facts.
I've been waiting for real data too, and there's not one shred of it, or
even a hint that it might appear.  So, the conclusion I'm coming to is
that there isn't any data to back up the claims made in this thread.

If it was such a problem, then in the _eight_ days that this has been
discussed so far, _someone_ would have sent some data showing the
problem.  I think the fact is, there is no data.

Someone prove me wrong.  Someone post the verifiable data showing that
there is a problem to be solved here.

Someone show what the specific failure cases are that are hampering
vendors moving forwards.  Someone show the long boot times by way of
kernel message log.  Someone show some evidence of the problems that
have been alluded to.

If no one can show some evidence, there isn't a problem here. :)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote:
> <oops, sent too early...>
> 
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> > Given that downstreams are already carrying as many hacks as they
> > could think of to speed total boot up, I think this is effectively
> > telling them to go away.
> 
> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> solve-the-random-issue-i'm-having type patch by putting random calls in
> semi-random subsystems all over the kernel.

+100000000000, fully agree.

There's too much verbal diarrhoea going on in this thread and no facts.
I've been waiting for real data too, and there's not one shred of it, or
even a hint that it might appear.  So, the conclusion I'm coming to is
that there isn't any data to back up the claims made in this thread.

If it was such a problem, then in the _eight_ days that this has been
discussed so far, _someone_ would have sent some data showing the
problem.  I think the fact is, there is no data.

Someone prove me wrong.  Someone post the verifiable data showing that
there is a problem to be solved here.

Someone show what the specific failure cases are that are hampering
vendors moving forwards.  Someone show the long boot times by way of
kernel message log.  Someone show some evidence of the problems that
have been alluded to.

If no one can show some evidence, there isn't a problem here. :)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: Alternative approach to solve the deferred probe

[Grygorii Strashko]

Hi Russell,

On 10/21/2015 09:28 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
>> But I worry a bit (and that my main point) about these few additional
>> rounds of deferred device probing which I have right now and which allows
>> some of drivers to finish, finally, their probes successfully.
>> With proposed change I'll get more messages in boot log, but some of
>> them will belong to drivers which have been probed successfully and so,
>> they will be not really useful.
> 
> Then you haven't properly understood my proposal.
> 
> I want to get rid of all the "X deferred its probing" messages up until
> the point that we set the "please report deferred probes" flag.
> 
> That _should_ mean that all the deferred probing that goes on becomes
> _totally_ silent and becomes hidden (unless you really want to see it,
> in which case we can make a debug option which turns it on) up until
> we're at the point where we want to enter userspace.
> 
> At that point, we then report into the kernel log which devices are
> still deferring and, via appropriately placed dev_warn_deferred(),
> the reasons why the devices are being deferred.
> 
> So, gone will be all the messages earlier in the log about device X
> not having a GPIO/clock/whatever because the device providing the
> GPIO/clock/whatever hasn't been probed.
> 
> If everything is satisfied by the time we run this last round (again,
> I'm not using a three line sentence to describe exactly what I mean,
> I'm sure you know by now... oops, I just did) then the kernel will
> report nothing about any deferrals.  That's _got_ to be an improvement.

Sorry Master, but you really don't need to spend so much time typing the
same things three times  - I understand what are you trying to do :(

I did my comments with assumption that it's not officially prohibited/deprecated
to register drivers (and execute probes) from late_initcall() layer
(just recommended) and there are still bunch of drivers which are doing this.
Now I see that it's not a recommendation any more, and deferred_probe_initcall()
might be a good place to activate driver_deferred_probe_report if goal is to
identify and fix such drivers.

Sorry for your time.

> 
>>
>> As result, I think, the most important thing is to identify (or create)
>> some point during kernel boot when it will be possible to say that all
>> built-in drivers (at least) finish their probes 100% (done or defer).
>>
>> Might be do_initcalls() can be updated (smth like this):
>> static void __init do_initcalls(void)
>> {
>> 	int level;
>>
>> 	for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
>> 		do_initcall_level(level);
>>
>> +	wait_for_device_probe();
>> +	/* Now one final round, reporting any devices that remain deferred */
>> +	driver_deferred_probe_report = true;
>> +	driver_deferred_probe_trigger();
>> +	wait_for_device_probe();
>> }
>>
>> Also, in my opinion, it will be useful if this debugging feature will be
>> optional.
> 
> I wonder why you want it optional... so I'm going to guess and cover
> both cases I can think of below to head off another round of reply on
> this point (sorry if this sucks eggs.)
> 
> I don't see it as being optional, because it's going to be cheap to run
> in the case of a system which has very few or no errors - which is what
> you should have for production systems, right?
> 

Also, I've spend some time today testing your proposal - hope you'll find results
useful.

I've applied truncated version of your patch (diff below) on TI's 4.1 kernel and
run few tests (log is below) on dra7-evm/am43xx-gpevm - K4.1 is not far away from LKML,
so I assume this test is valid. Overall boot process consists from two stages:
kernel boot and modules loading. 

My Changes:
 - only really_probe() modified to show deferred device/drivers 

From the log I can see additional messages in log when modules are loading,
because driver_deferred_probe_report is still true - dwc3 probes were deferred,
but then finally succeeded.

So, as you've mentioned, it seems a good thing to deactivate driver_deferred_probe_report and
provide user with ability to turn it on again (and probably re-trigger deferred
device probing).

I've found no issues during Kernel boot (built-in) time, new messages are displayed only
if probe is failed for some drivers:
[    3.219700] ====================================== deferred_probe_initcalll
[    3.226820] platform omapdrm.0: Driver omapdrm requests probe deferral
[    3.233378] platform omapdrm.0: deferring probe: ==== Driver omapdrm requests probe deferral
[    3.242084] dra7evm-tpd12s015 encoder@1: failed to parse CT CP HPD gpio
[    3.248737] platform encoder@1: Driver dra7evm-tpd12s015 requests probe deferral
[    3.256168] platform encoder@1: deferring probe: ==== Driver dra7evm-tpd12s015 requests probe deferral
[    3.265763] connector-hdmi connector@1: failed to find video source
[    3.272067] platform connector@1: Driver connector-hdmi requests probe deferral
[    3.279410] platform connector@1: deferring probe: ==== Driver connector-hdmi requests probe deferral 
^^ above drivers will be deferred forever

Thanks.
-- 
regards,
-grygorii
S/ILKP

*************** [TEST CODE] ***********
---
 drivers/base/dd.c | 33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index e7d2545..d61fa47 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -129,6 +129,27 @@ void driver_deferred_probe_del(struct device *dev)
 	mutex_unlock(&deferred_probe_mutex);
 }
 
+static bool driver_deferred_probe_report;
+
+/**
+ * dev_warn_deferred() - report why a probe has been deferred
+ */
+void dev_warn_deferred(struct device *dev, const char *fmt, ...)
+{
+	if (driver_deferred_probe_report) {
+		struct va_format vaf;
+		va_list ap;
+
+		va_start(ap, fmt);
+		vaf.fmt = fmt;
+		vaf.va = &ap;
+
+		dev_err(dev, "deferring probe: %pV", &vaf);
+		va_end(ap);
+	}
+}
+EXPORT_SYMBOL_GPL(dev_warn_deferred);
+
 static bool driver_deferred_probe_enable = false;
 /**
  * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
@@ -188,6 +209,15 @@ static int deferred_probe_initcall(void)
 	driver_deferred_probe_trigger();
 	/* Sort as many dependencies as possible before exiting initcalls */
 	flush_workqueue(deferred_wq);
+
+	pr_err("====================================== deferred_probe_initcalll\n");
+
+	/* Now one final round, reporting any devices that remain deferred */
+	driver_deferred_probe_report = true;
+	driver_deferred_probe_trigger();
+	/* Sort as many dependencies as possible before exiting initcalls */
+	flush_workqueue(deferred_wq);
+
 	return 0;
 }
 late_initcall(deferred_probe_initcall);
@@ -342,7 +372,8 @@ probe_failed:
 	switch (ret) {
 	case -EPROBE_DEFER:
 		/* Driver requested deferred probing */
-		dev_dbg(dev, "Driver %s requests probe deferral\n", drv->name);
+		dev_err(dev, "Driver %s requests probe deferral\n", drv->name);
+		dev_warn_deferred(dev, "==== Driver %s requests probe deferral\n", drv->name);
 		driver_deferred_probe_add(dev);
 		/* Did a trigger occur while probing? Need to re-trigger if yes */
 		if (local_trigger_count != atomic_read(&deferred_trigger_count))
-- 
2.6.2


*************** [BOOT LOG] ***********
Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.1.10-rt10-02639-gd63d0be-dirty (lcpdbld@dflsdit-build06.dal.design.ti.com) (gcc version 4.9.3 20150413 (prerelease) (Linaro GCC 4.9-2015.05) ) #1 SMP PREEMPT RT Thu Oct 22 05:11:58 CDT 2015
[    0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] Machine model: TI DRA742
[    0.000000] Reserved memory: created CMA memory pool at 0x95800000, size 56 MiB
[    0.000000] Reserved memory: initialized node ipu2_cma@95800000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x99000000, size 64 MiB
[    0.000000] Reserved memory: initialized node dsp1_cma@99000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x9d000000, size 32 MiB
[    0.000000] Reserved memory: initialized node ipu1_cma@9d000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x9f000000, size 8 MiB
[    0.000000] Reserved memory: initialized node dsp2_cma@9f000000, compatible id shared-dma-pool
[    0.000000] cma: Reserved 24 MiB at 0xde000000
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] DRA752 ES1.1
[    0.000000] PERCPU: Embedded 12 pages/cpu @ee9af000 s17792 r8192 d23168 u49152
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 390994
[    0.000000] Kernel command line: console=ttyO0,115200n8 earlyprintk rootwait  ip=:::::eth0:dhcp  root=/dev/nfs rw nfsroot=192.168.0.1:/home/tigtfarm07/NFS_exports/dra7xx-evm1/autofs/1d8e30535854dc371534f96e3c6d5488,nolock 
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 1356664K/1570816K available (6271K kernel code, 508K rwdata, 2240K rodata, 372K init, 266K bss, 25736K reserved, 188416K cma-reserved, 768000K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0858064   (8513 kB)
[    0.000000]       .init : 0xc0859000 - 0xc08b6000   ( 372 kB)
[    0.000000]       .data : 0xc08b6000 - 0xc09352c0   ( 509 kB)
[    0.000000]        .bss : 0xc0938000 - 0xc097ab78   ( 267 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] 	Additional per-CPU info printed with stalls.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] 	Offload RCU callbacks from all CPUs
[    0.000000] 	Offload RCU callbacks from CPUs: 0-1.
[    0.000000] OMAP clockevent source: timer1 at 32768 Hz
[    0.000000] clocksource 32k_counter: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 65535999984741ns
[    0.000000] OMAP clocksource: 32k_counter at 32768 Hz
[    0.000427] Architected cp15 timer(s) running at 6.14MHz (virt).
[    0.000457] clocksource arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x16af5adb9, max_idle_ns: 440795202250 ns
[    0.000463] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511023ns
[    0.000470] Switching to timer-based delay loop, resolution 162ns
[    0.001360] Console: colour dummy device 80x30
[    0.001486] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
[    0.001488] This ensures that you still see kernel messages. Please
[    0.001489] update your kernel commandline.
[    0.001502] Calibrating delay loop (skipped), value calculated using timer frequency.. 12.29 BogoMIPS (lpj=61475)
[    0.001506] pid_max: default: 32768 minimum: 301
[    0.001583] Security Framework initialized
[    0.001620] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.001626] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.002189] Initializing cgroup subsys blkio
[    0.002197] Initializing cgroup subsys memory
[    0.002221] Initializing cgroup subsys devices
[    0.002228] Initializing cgroup subsys freezer
[    0.002236] Initializing cgroup subsys perf_event
[    0.002278] CPU: Testing write buffer coherency: ok
[    0.002517] /cpus/cpu@0 missing clock-frequency property
[    0.002598] /cpus/cpu@1 missing clock-frequency property
[    0.002609] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.002653] Setting up static identity map for 0x80008280 - 0x800082f0
[    0.120957] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.121040] Brought up 2 CPUs
[    0.121054] SMP: Total of 2 processors activated (24.59 BogoMIPS).
[    0.121061] CPU: All CPU(s) started in SVC mode.
[    0.121513] devtmpfs: initialized
[    0.149180] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
[    0.149968] omap_hwmod: l3_main_2 using broken dt data from ocp
[    0.164029] omap_hwmod: tptc0 using broken dt data from edma-controller
[    0.164509] omap_hwmod: tptc1 using broken dt data from edma-controller
[    0.338569] clocksource jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.342242] pinctrl core: initialized pinctrl subsystem
[    0.343204] NET: Registered protocol family 16
[    0.345772] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.354459] OMAP GPIO hardware version 0.1
[    0.362174] irq: no irq domain found for /ocp/l4@4a000000/scm@2000/pinmux@1400 !
[    0.388931] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[    0.388942] hw-breakpoint: maximum watchpoint size is 8 bytes.
[    0.391765] omap4_sram_init:Unable to allocate sram needed to handle errata I688
[    0.391775] omap4_sram_init:Unable to get sram pool needed to handle errata I688
[    0.392434] OMAP DMA hardware revision 0.0
[    0.409403] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver
[    0.412466] omap-dma-engine 4a056000.dma-controller: OMAP DMA engine driver
[    0.413035] platform fixedregulator-sd: Driver reg-fixed-voltage requests probe deferral
[    0.418357] omap-iommu 40d01000.mmu: 40d01000.mmu registered
[    0.418619] omap-iommu 40d02000.mmu: 40d02000.mmu registered
[    0.418864] omap-iommu 58882000.mmu: 58882000.mmu registered
[    0.419116] omap-iommu 55082000.mmu: 55082000.mmu registered
[    0.419488] omap-iommu 41501000.mmu: 41501000.mmu registered
[    0.419750] omap-iommu 41502000.mmu: 41502000.mmu registered
[    0.420001] vgaarb: loaded
[    0.420424] SCSI subsystem initialized
[    0.421911] palmas 0-0058: IRQ missing: skipping irq request
[    0.441468] palmas 0-0058: Muxing GPIO 2e, PWM 0, LED 0
[    0.513681] pcf857x 0-0020: probed
[    0.514304] pcf857x 0-0021: probed
[    0.514450] omap_i2c 48070000.i2c: bus 0 rev0.12 at 400 kHz
[    0.531230] GPIO line 465 (vin6_sel_s0) hogged as output/low
[    0.531421] pcf857x 1-0026: probed
[    0.531580] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
[    0.532021] omap_i2c 48060000.i2c: bus 2 rev0.12 at 400 kHz
[    0.532308] pps_core: LinuxPPS API ver. 1 registered
[    0.532317] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.532346] PTP clock support registered
[    0.533009] omap-mailbox 48840000.mailbox: omap mailbox rev 0x400
[    0.533319] omap-mailbox 48842000.mailbox: omap mailbox rev 0x400
[    0.533623] Advanced Linux Sound Architecture Driver Initialized.
[    0.534366] Switched to clocksource arch_sys_counter
[    0.544551] NET: Registered protocol family 2
[    0.545253] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    0.545334] TCP bind hash table entries: 8192 (order: 5, 229376 bytes)
[    0.545623] TCP: Hash tables configured (established 8192 bind 8192)
[    0.545685] UDP hash table entries: 512 (order: 3, 32768 bytes)
[    0.545741] UDP-Lite hash table entries: 512 (order: 3, 32768 bytes)
[    0.545949] NET: Registered protocol family 1
[    0.546240] RPC: Registered named UNIX socket transport module.
[    0.546249] RPC: Registered udp transport module.
[    0.546256] RPC: Registered tcp transport module.
[    0.546263] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.547419] CPU PMU: Failed to parse /pmu/interrupt-affinity[0]
[    0.547454] hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
[    0.549458] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.549541] audit: initializing netlink subsys (disabled)
[    0.549576] audit: type=2000 audit(0.530:1): initialized
[    0.556198] VFS: Disk quotas dquot_6.6.0
[    0.556369] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.558508] NFS: Registering the id_resolver key type
[    0.558542] Key type id_resolver registered
[    0.558550] Key type id_legacy registered
[    0.558610] jffs2: version 2.2. (NAND) (SUMMARY)   2001-2006 Red Hat, Inc.
[    0.560591] NET: Registered protocol family 38
[    0.560698] bounce: pool size: 64 pages
[    0.560713] io scheduler noop registered
[    0.560727] io scheduler deadline registered
[    0.560879] io scheduler cfq registered (default)
[    0.564728] pinctrl-single 4a003400.pinmux: 281 pins at pa fc003400 size 1124
[    0.574576] dra7-pcie 51000000.pcie: PCI host bridge to bus 0000:00
[    0.574590] pci_bus 0000:00: root bus resource [io  0x1000-0xffff]
[    0.574600] pci_bus 0000:00: root bus resource [mem 0x20013000-0x2fffffff]
[    0.574612] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.574765] pci 0000:00:00.0: IOMMU is currently not supported for PCI
[    0.575026] PCI: bus0: Fast back to back transfers disabled
[    0.575470] pci 0000:01:00.0: IOMMU is currently not supported for PCI
[    0.575814] PCI: bus1: Fast back to back transfers disabled
[    0.575950] pci 0000:00:00.0: BAR 0: assigned [mem 0x20100000-0x201fffff]
[    0.575966] pci 0000:00:00.0: BAR 8: assigned [mem 0x20200000-0x202fffff]
[    0.575978] pci 0000:00:00.0: BAR 9: assigned [mem 0x20300000-0x203fffff pref]
[    0.575989] pci 0000:00:00.0: BAR 1: assigned [mem 0x20020000-0x2002ffff]
[    0.576002] pci 0000:00:00.0: BAR 7: assigned [io  0x1000-0x1fff]
[    0.576017] pci 0000:01:00.0: BAR 1: assigned [mem 0x20200000-0x2027ffff]
[    0.576037] pci 0000:01:00.0: BAR 6: assigned [mem 0x20300000-0x2033ffff pref]
[    0.576048] pci 0000:01:00.0: BAR 0: assigned [mem 0x20280000-0x2029ffff]
[    0.576067] pci 0000:01:00.0: BAR 3: assigned [mem 0x202a0000-0x202a3fff]
[    0.576086] pci 0000:01:00.0: BAR 2: assigned [io  0x1000-0x101f]
[    0.576106] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.576116] pci 0000:00:00.0:   bridge window [io  0x1000-0x1fff]
[    0.576128] pci 0000:00:00.0:   bridge window [mem 0x20200000-0x202fffff]
[    0.576138] pci 0000:00:00.0:   bridge window [mem 0x20300000-0x203fffff pref]
[    0.579925] OMAP DSS rev 6.1
[    0.580244] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dispc_component_ops)
[    0.580839] omapdss_dss 58000000.dss: bound 58040000.encoder (ops hdmi5_component_ops)
[    0.581749] platform encoder@1: Driver dra7evm-tpd12s015 requests probe deferral
[    0.582201] connector-hdmi connector@1: failed to find video source
[    0.582219] platform connector@1: Driver connector-hdmi requests probe deferral
[    0.585743] Serial: 8250/16550 driver, 10 ports, IRQ sharing enabled
[    0.588508] 4806a000.serial: ttyS0 at MMIO 0x4806a000 (irq = 299, base_baud = 3000000) is a 8250
[    1.662547] console [ttyS0] enabled
[    1.666661] 4806c000.serial: ttyS1 at MMIO 0x4806c000 (irq = 300, base_baud = 3000000) is a 8250
[    1.676287] 48020000.serial: ttyS2 at MMIO 0x48020000 (irq = 301, base_baud = 3000000) is a 8250
[    1.686280] [drm] Initialized drm 1.1.0 20060810
[    1.700726] brd: module loaded
[    1.708417] loop: module loaded
[    1.712651] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.723546] mousedev: PS/2 mouse device common for all mice
[    1.729154] i2c /dev entries driver
[    1.734581] omap_hsmmc 4809c000.mmc: Got CD GPIO
[    1.739413] omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
[    1.746235] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
[    1.753335] platform 4809c000.mmc: Driver omap_hsmmc requests probe deferral
[    1.760862] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr104 mode
[    1.767334] omap_hsmmc 480b4000.mmc: no pinctrl state for hs200_1_8v mode
[    1.774151] omap_hsmmc 480b4000.mmc: no pinctrl state for ddr50 mode
[    1.780537] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr50 mode
[    1.786920] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
[    1.793302] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
[    1.800000] evm_3v3_sw: supplied by sysen1
[    1.845119] omap_hsmmc 480d1000.mmc: no pinctrl state for sdr104 mode
[    1.851589] omap_hsmmc 480d1000.mmc: no pinctrl state for hs200_1_8v mode
[    1.858426] omap_hsmmc 480d1000.mmc: no pinctrl state for ddr50 mode
[    1.864810] omap_hsmmc 480d1000.mmc: no pinctrl state for sdr50 mode
[    1.871192] omap_hsmmc 480d1000.mmc: no pinctrl state for ddr_1_8v mode
[    1.888212] mmc0: MAN_BKOPS_EN bit is not set
[    1.896106] mmc0: new DDR MMC card at address 0001
[    1.901266] mmcblk0: mmc0:0001 MMC08G 7.25 GiB 
[    1.905933] mmcblk0boot0: mmc0:0001 MMC08G partition 1 8.00 MiB
[    1.911994] mmcblk0boot1: mmc0:0001 MMC08G partition 2 8.00 MiB
[    1.918716]  mmcblk0: p1 p2 p3
[    1.995125] omap-aes 4b500000.aes: OMAP AES hw accel rev: 3.3
[    2.001694] omap-aes 4b700000.aes: OMAP AES hw accel rev: 3.3
[    2.009016] omap-des 480a5000.des: OMAP DES hw accel rev: 2.2
[    2.015924] omap-sham 4b101000.sham: hw accel on OMAP rev 4.3
[    2.026077] davinci-mcasp 48468000.mcasp: ERRATA i868 workaround is enabled
[    2.035132] davinci-mcasp 4847c000.mcasp: ERRATA i868 workaround is enabled
[    2.042544] Initializing XFRM netlink socket
[    2.046882] NET: Registered protocol family 17
[    2.051375] NET: Registered protocol family 15
[    2.055925] Key type dns_resolver registered
[    2.060338] omap_voltage_late_init: Voltage driver support not added
[    2.066734] sr_dev_init: Unable to get voltage domain pointer for VDD core
[    2.073638] sr_dev_init: Unable to get voltage domain pointer for VDD mpu
[    2.080738] Power Management for TI OMAP4+ devices.
[    2.085863] ThumbEE CPU extension supported.
[    2.090164] Registering SWP/SWPB emulation handler
[    2.094984] SmartReflex Class3 initialized
[    2.100743] dmm 4e000000.dmm: workaround for errata i878 in use
[    2.108418] dmm 4e000000.dmm: initialized all PAT entries
[    2.114210] platform omapdrm.0: Driver omapdrm requests probe deferral
[    2.123162] omap_hsmmc 4809c000.mmc: Got CD GPIO
[    2.128009] omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
[    2.134830] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
[    2.196401] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    2.203044] [drm] No driver support for vblank timestamp query.
[    2.209023] omapdrm omapdrm.0: No connectors reported connected with modes
[    2.215933] [drm] Cannot find any crtc or sizes - going 1024x768
[    2.227640] [drm] Enabling DMM ywrap scrolling
[    2.239535] Console: switching to colour frame buffer device 128x48
[    2.251305] omapdrm omapdrm.0: fb0: omapdrm frame buffer device
[    2.257253] omapdrm omapdrm.0: registered panic notifier
[    2.274429] [drm] Initialized omapdrm 1.0.0 20110917 on minor 0
[    2.280400] ====================================== deferred_probe_initcalll
[    2.334387] davinci_mdio 48485000.mdio: davinci mdio revision 1.6
[    2.340513] davinci_mdio 48485000.mdio: detected phy mask fffffff3
[    2.344381] mmc2: host does not support reading read-only switch, assuming write-enable
[    2.349716] mmc2: new high speed SDHC card at address e624
[    2.354396] mmcblk1: mmc2:e624 SU04G 3.69 GiB 
[    2.362506]  mmcblk1: p1 p2 p3
[    2.372593] libphy: 48485000.mdio: probed
[    2.376626] davinci_mdio 48485000.mdio: phy[2]: device 48485000.mdio:02, driver unknown
[    2.384668] davinci_mdio 48485000.mdio: phy[3]: device 48485000.mdio:03, driver unknown
[    2.393389] cpsw 48484000.ethernet: Detected MACID = b4:99:4c:0b:e4:e6
[    2.400896] cpsw 48484000.ethernet: cpsw: Detected MACID = b4:99:4c:0b:e4:e7
[    2.408583] hctosys: unable to open rtc device (rtc0)
[    2.413661] sr_init: No PMIC hook to init smartreflex
[    2.418903] sr_init: platform driver register failed for SR
[    2.441783] net eth0: initializing cpsw version 1.15 (0)
[    2.528312] net eth0: phy found : id is : 0x20005c7a
[    6.531286] cpsw 48484000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[    6.554382] Sending DHCP requests ., OK
[    6.624439] IP-Config: Got DHCP answer from 192.168.0.1, my address is 192.168.0.192
[    6.632426] IP-Config: Complete:
[    6.635674]      device=eth0, hwaddr=b4:99:4c:0b:e4:e6, ipaddr=192.168.0.192, mask=255.255.255.0, gw=192.168.0.1
[    6.645895]      host=192.168.0.192, domain=ti.com, nis-domain=(none)
[    6.652364]      bootserver=192.168.0.1, rootserver=192.168.0.1, rootpath=
[    6.659095]      nameserver0=192.0.2.2, nameserver1=192.0.2.3
[    6.665282] ldousb: disabling
[    6.668549] vmmcwl_fixed: disabling
[    6.672054] aic_dvdd: disabling
[    6.675417] ALSA device list:
[    6.678397]   No soundcards found.
[    6.687614] VFS: Mounted root (nfs filesystem) on device 0:15.
[    6.693779] devtmpfs: mounted
[    6.697044] Freeing unused kernel memory: 372K (c0859000 - c08b6000)

INIT: version 2.88 booting

Starting udev
[    7.129889] udevd[175]: starting version 182
[    7.329630] omap-rproc 58820000.ipu: assigned reserved memory node ipu1_cma@9d000000
[    7.349436]  remoteproc0: 58820000.ipu is available
[    7.358961]  remoteproc0: Note: remoteproc is still under development and considered experimental.
[    7.431205]  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.452181]  remoteproc0: Direct firmware load for dra7-ipu1-fw.xem4 failed with error -2
[    7.456683] omap-rproc 55020000.ipu: assigned reserved memory node ipu2_cma@95800000
[    7.471645]  remoteproc1: 55020000.ipu is available
[    7.471649]  remoteproc1: Note: remoteproc is still under development and considered experimental.
[    7.471653]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.480262] omap-rproc 40800000.dsp: assigned reserved memory node dsp1_cma@99000000
[    7.510612]  remoteproc2: 40800000.dsp is available
[    7.510618]  remoteproc2: Note: remoteproc is still under development and considered experimental.
[    7.510622]  remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.514543] omap-rproc 41000000.dsp: assigned reserved memory node dsp2_cma@9f000000
[    7.523301]  remoteproc3: 41000000.dsp is available
[    7.523306]  remoteproc3: Note: remoteproc is still under development and considered experimental.
[    7.523309]  remoteproc3: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.614060]  remoteproc0: Falling back to user helper
[    7.672048] aic_dvdd: supplied by evm_3v3_sw
[    7.736112] omap_rng 48090000.rng: OMAP Random Number Generator ver. 20
[    8.067185] media: Linux media interface: v0.10
[    8.216475] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc as rtc0
[    8.217206] Linux video capture interface: v2.00
[    8.276707] random: nonblocking pool is initialized
[    8.394957] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    8.420281] platform 48880000.omap_dwc3_1: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    8.423788] ov1063x 1-0037: Failed writing register 0x0103!
[    8.423807] ov1063x: probe of 1-0037 failed with error -121
[    8.488870]  remoteproc0: failed to load dra7-ipu1-fw.xem4
[    8.729862] platform 488c0000.omap_dwc3_2: Driver omap-dwc3 requests probe deferral
[    8.733069] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    8.733072] e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
[    8.733178] e1000e 0000:01:00.0: enabling device (0140 -> 0142)
[    8.733435] e1000e 0000:01:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    8.750383] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[    8.750685] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    8.750692] platform 48880000.omap_dwc3_1: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    8.779935] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[    8.780067] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    8.780073] platform 48880000.omap_dwc3_1: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    8.951061] CAN device driver interface
[    8.963296] e1000e 0000:01:00.0 eth2: registered PHC clock
[    8.963304] e1000e 0000:01:00.0 eth2: (PCI Express:2.5GT/s:Width x1) 68:05:ca:36:2b:25
[    8.963311] e1000e 0000:01:00.0 eth2: Intel(R) PRO/1000 Network Connection
[    8.966445] e1000e 0000:01:00.0 eth2: MAC: 3, PHY: 8, PBA No: E46981-008
[    9.024825] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[    9.027031] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    9.027039] platform 48880000.omap_dwc3_1: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    9.287323]  remoteproc2: Direct firmware load for dra7-dsp1-fw.xe66 failed with error -2
[    9.287327]  remoteproc2: Falling back to user helper
[    9.308265] omap-dwc3 48880000.omap_dwc3_1: **** dwc3_omap_probe done
[    9.341969] platform 488c0000.omap_dwc3_2: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    9.357153] vpe 489d0000.vpe: loading firmware vpdma-1b8.bin
[    9.363840]  remoteproc1: registered virtio0 (type 7)
[    9.390936] omap-dwc3 488c0000.omap_dwc3_2: **** dwc3_omap_probe done
[    9.411821] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    9.487056] input: gpio_keys as /devices/platform/gpio_keys/input/input0
[    9.530380] asoc-simple-card sound@0: tlv320aic3x-hifi <-> 48468000.mcasp mapping ok
[    9.572735] c_can_platform 4ae3c000.can: c_can_platform device registered (regs=fce3c000, irq=349)
[    9.585025] vip 48970000.vip: loading firmware vpdma-1b8.bin
[    9.592896] ahci 4a140000.sata: SSS flag set, parallel bus scan disabled
[    9.599650] ahci 4a140000.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[    9.608289] ahci 4a140000.sata: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part ccc apst 
[    9.703388] scsi host0: ahci
[    9.763672] omap-hdmi-audio omap-hdmi-audio.0.auto: snd-soc-dummy-dai <-> 58040000.encoder mapping ok
[    9.803153] ata1: SATA max UDMA/133 mmio [mem 0x4a140000-0x4a1410ff] port 0x100 irq 336
[   10.164442] ata1: SATA link down (SStatus 0 SControl 300)
[   10.642315]  remoteproc2: failed to load dra7-dsp1-fw.xe66
[   10.659698]  remoteproc3: Direct firmware load for dra7-dsp2-fw.xe66 failed with error -2
[   10.671669]  remoteproc3: Falling back to user helper
[   10.811525]  remoteproc1: powering up 55020000.ipu
[   10.820600] m25p80 spi32766.0: s25fl256s1 (32768 Kbytes)
[   10.820686] 10 ofpart partitions found on MTD device spi32766.0
[   10.820693] Creating 10 MTD partitions on "spi32766.0":
[   10.820702] 0x000000000000-0x000000010000 : "QSPI.SPL"
[   10.886395] 0x000000010000-0x000000020000 : "QSPI.SPL.backup1"
[   10.895608]  remoteproc3: failed to load dra7-dsp2-fw.xe66
[   10.909877] 0x000000020000-0x000000030000 : "QSPI.SPL.backup2"
[   10.912583] 0x000000030000-0x000000040000 : "QSPI.SPL.backup3"
[   10.913546] 0x000000040000-0x000000140000 : "QSPI.u-boot"
[   10.914433] vip 48970000.vip: VPDMA firmware loaded
[   10.914670] vpe 489d0000.vpe: Device registered as /dev/video0
[   10.938439] 0x000000140000-0x0000001c0000 : "QSPI.u-boot-spl-os"
[   10.962444] 0x0000001c0000-0x0000001d0000 : "QSPI.u-boot-env"
[   11.011549] 0x0000001d0000-0x0000001e0000 : "QSPI.u-boot-env.backup1"
[   11.071277] 0x0000001e0000-0x0000009e0000 : "QSPI.kernel"
[   11.080616] 0x0000009e0000-0x000002000000 : "QSPI.file-system"
[   11.415621] EXT4-fs (mmcblk0p3): mounted filesystem without journal. Opts: (null)
[   11.439508] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   11.476702]  remoteproc1: Booting fw image dra7-ipu2-fw.xem4, size 3480916
[   11.491518] EXT4-fs (mmcblk1p3): mounted filesystem without journal. Opts: (null)
[   11.495115] EXT4-fs (mmcblk1p2): warning: maximal mount count reached, running e2fsck is recommended
[   11.505950] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)
[   11.536011] FAT-fs (mmcblk0p2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   11.641063] FAT-fs (mmcblk1p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   11.690531] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
[   11.894821] dwc3 48890000.usb: **** dwc3_probe done
[   11.972740]  remoteproc1: remote processor 55020000.ipu is now up
[   11.999719] virtio_rpmsg_bus virtio0: rpmsg host is online
[   12.003008] virtio_rpmsg_bus virtio0: creating channel rpmsg-rpc addr 0x3b
[   12.085055] rpmsg_rpc rpmsg0: probing service rpmsg-dce with src 1024 dst 59
[   12.092778] rpmsg_rpc rpmsg0: published functions = 8
[   12.387531] dwc3 488d0000.usb: **** dwc3_probe done
[   12.555405] usbcore: registered new interface driver usbfs
[   12.561001] usbcore: registered new interface driver hub
[   12.566496] usbcore: registered new device driver usb
[   12.619632] dwc3 48890000.usb: otg: primary host xhci-hcd.1.auto registered
[   12.626635] dwc3 48890000.usb: otg: shared host xhci-hcd.1.auto registered
[   12.633543] dwc3 48890000.usb: otg: can't start till gadget registers
[   12.640118] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[   12.645652] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 1
[   12.653905] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[   12.662779] xhci-hcd xhci-hcd.2.auto: irq 463, io mem 0x488d0000
[   12.668985] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[   12.681600] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   12.688857] usb usb1: Product: xHCI Host Controller
[   12.693757] usb usb1: Manufacturer: Linux 4.1.10-rt10-02639-gd63d0be-dirty xhci-hcd
[   12.701448] usb usb1: SerialNumber: xhci-hcd.2.auto
[   12.707274] hub 1-0:1.0: USB hub found
[   12.711077] hub 1-0:1.0: 1 port detected
[   12.715501] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[   12.721021] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 2
[   12.728804] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[   12.737061] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[   12.743880] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   12.751136] usb usb2: Product: xHCI Host Controller
[   12.756039] usb usb2: Manufacturer: Linux 4.1.10-rt10-02639-gd63d0be-dirty xhci-hcd
[   12.763727] usb usb2: SerialNumber: xhci-hcd.2.auto
[   12.769500] hub 2-0:1.0: USB hub found
[   12.773298] hub 2-0:1.0: 1 port detected
bootlogd: cannot allocate pseudo tty: No such file or directory
Starting random number generator daemon.
[   13.034435] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[   13.176262] usb 1-1: New USB device found, idVendor=154b, idProduct=007a
[   13.183002] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   13.190859] usb 1-1: Product: USB 2.0 FD
[   13.194810] usb 1-1: Manufacturer: PNY Technologies
[   13.199717] usb 1-1: SerialNumber: AEC12H25YE11003156
[   13.209498] usb 1-1: ep 0x81 - rounding interval to 128 microframes, ep desc says 255 microframes
[   13.218598] usb 1-1: ep 0x2 - rounding interval to 128 microframes, ep desc says 255 microframes
[   13.280307] usb-storage 1-1:1.0: USB Mass Storage device detected
[   13.287194] scsi host1: usb-storage 1-1:1.0
[   13.293029] usbcore: registered new interface driver usb-storage

Re: Alternative approach to solve the deferred probe

[Grygorii Strashko]

Hi Russell,

On 10/21/2015 09:28 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
>> But I worry a bit (and that my main point) about these few additional
>> rounds of deferred device probing which I have right now and which allows
>> some of drivers to finish, finally, their probes successfully.
>> With proposed change I'll get more messages in boot log, but some of
>> them will belong to drivers which have been probed successfully and so,
>> they will be not really useful.
> 
> Then you haven't properly understood my proposal.
> 
> I want to get rid of all the "X deferred its probing" messages up until
> the point that we set the "please report deferred probes" flag.
> 
> That _should_ mean that all the deferred probing that goes on becomes
> _totally_ silent and becomes hidden (unless you really want to see it,
> in which case we can make a debug option which turns it on) up until
> we're at the point where we want to enter userspace.
> 
> At that point, we then report into the kernel log which devices are
> still deferring and, via appropriately placed dev_warn_deferred(),
> the reasons why the devices are being deferred.
> 
> So, gone will be all the messages earlier in the log about device X
> not having a GPIO/clock/whatever because the device providing the
> GPIO/clock/whatever hasn't been probed.
> 
> If everything is satisfied by the time we run this last round (again,
> I'm not using a three line sentence to describe exactly what I mean,
> I'm sure you know by now... oops, I just did) then the kernel will
> report nothing about any deferrals.  That's _got_ to be an improvement.

Sorry Master, but you really don't need to spend so much time typing the
same things three times  - I understand what are you trying to do :(

I did my comments with assumption that it's not officially prohibited/deprecated
to register drivers (and execute probes) from late_initcall() layer
(just recommended) and there are still bunch of drivers which are doing this.
Now I see that it's not a recommendation any more, and deferred_probe_initcall()
might be a good place to activate driver_deferred_probe_report if goal is to
identify and fix such drivers.

Sorry for your time.

> 
>>
>> As result, I think, the most important thing is to identify (or create)
>> some point during kernel boot when it will be possible to say that all
>> built-in drivers (at least) finish their probes 100% (done or defer).
>>
>> Might be do_initcalls() can be updated (smth like this):
>> static void __init do_initcalls(void)
>> {
>> 	int level;
>>
>> 	for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
>> 		do_initcall_level(level);
>>
>> +	wait_for_device_probe();
>> +	/* Now one final round, reporting any devices that remain deferred */
>> +	driver_deferred_probe_report = true;
>> +	driver_deferred_probe_trigger();
>> +	wait_for_device_probe();
>> }
>>
>> Also, in my opinion, it will be useful if this debugging feature will be
>> optional.
> 
> I wonder why you want it optional... so I'm going to guess and cover
> both cases I can think of below to head off another round of reply on
> this point (sorry if this sucks eggs.)
> 
> I don't see it as being optional, because it's going to be cheap to run
> in the case of a system which has very few or no errors - which is what
> you should have for production systems, right?
> 

Also, I've spend some time today testing your proposal - hope you'll find results
useful.

I've applied truncated version of your patch (diff below) on TI's 4.1 kernel and
run few tests (log is below) on dra7-evm/am43xx-gpevm - K4.1 is not far away from LKML,
so I assume this test is valid. Overall boot process consists from two stages:
kernel boot and modules loading. 

My Changes:
 - only really_probe() modified to show deferred device/drivers 

>From the log I can see additional messages in log when modules are loading,
because driver_deferred_probe_report is still true - dwc3 probes were deferred,
but then finally succeeded.

So, as you've mentioned, it seems a good thing to deactivate driver_deferred_probe_report and
provide user with ability to turn it on again (and probably re-trigger deferred
device probing).

I've found no issues during Kernel boot (built-in) time, new messages are displayed only
if probe is failed for some drivers:
[    3.219700] ====================================== deferred_probe_initcalll
[    3.226820] platform omapdrm.0: Driver omapdrm requests probe deferral
[    3.233378] platform omapdrm.0: deferring probe: ==== Driver omapdrm requests probe deferral
[    3.242084] dra7evm-tpd12s015 encoder@1: failed to parse CT CP HPD gpio
[    3.248737] platform encoder@1: Driver dra7evm-tpd12s015 requests probe deferral
[    3.256168] platform encoder@1: deferring probe: ==== Driver dra7evm-tpd12s015 requests probe deferral
[    3.265763] connector-hdmi connector@1: failed to find video source
[    3.272067] platform connector@1: Driver connector-hdmi requests probe deferral
[    3.279410] platform connector@1: deferring probe: ==== Driver connector-hdmi requests probe deferral 
^^ above drivers will be deferred forever

Thanks.
-- 
regards,
-grygorii
S/ILKP

*************** [TEST CODE] ***********
---
 drivers/base/dd.c | 33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index e7d2545..d61fa47 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -129,6 +129,27 @@ void driver_deferred_probe_del(struct device *dev)
 	mutex_unlock(&deferred_probe_mutex);
 }
 
+static bool driver_deferred_probe_report;
+
+/**
+ * dev_warn_deferred() - report why a probe has been deferred
+ */
+void dev_warn_deferred(struct device *dev, const char *fmt, ...)
+{
+	if (driver_deferred_probe_report) {
+		struct va_format vaf;
+		va_list ap;
+
+		va_start(ap, fmt);
+		vaf.fmt = fmt;
+		vaf.va = &ap;
+
+		dev_err(dev, "deferring probe: %pV", &vaf);
+		va_end(ap);
+	}
+}
+EXPORT_SYMBOL_GPL(dev_warn_deferred);
+
 static bool driver_deferred_probe_enable = false;
 /**
  * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
@@ -188,6 +209,15 @@ static int deferred_probe_initcall(void)
 	driver_deferred_probe_trigger();
 	/* Sort as many dependencies as possible before exiting initcalls */
 	flush_workqueue(deferred_wq);
+
+	pr_err("====================================== deferred_probe_initcalll\n");
+
+	/* Now one final round, reporting any devices that remain deferred */
+	driver_deferred_probe_report = true;
+	driver_deferred_probe_trigger();
+	/* Sort as many dependencies as possible before exiting initcalls */
+	flush_workqueue(deferred_wq);
+
 	return 0;
 }
 late_initcall(deferred_probe_initcall);
@@ -342,7 +372,8 @@ probe_failed:
 	switch (ret) {
 	case -EPROBE_DEFER:
 		/* Driver requested deferred probing */
-		dev_dbg(dev, "Driver %s requests probe deferral\n", drv->name);
+		dev_err(dev, "Driver %s requests probe deferral\n", drv->name);
+		dev_warn_deferred(dev, "==== Driver %s requests probe deferral\n", drv->name);
 		driver_deferred_probe_add(dev);
 		/* Did a trigger occur while probing? Need to re-trigger if yes */
 		if (local_trigger_count != atomic_read(&deferred_trigger_count))
-- 
2.6.2


*************** [BOOT LOG] ***********
Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.1.10-rt10-02639-gd63d0be-dirty (lcpdbld@dflsdit-build06.dal.design.ti.com) (gcc version 4.9.3 20150413 (prerelease) (Linaro GCC 4.9-2015.05) ) #1 SMP PREEMPT RT Thu Oct 22 05:11:58 CDT 2015
[    0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] Machine model: TI DRA742
[    0.000000] Reserved memory: created CMA memory pool at 0x95800000, size 56 MiB
[    0.000000] Reserved memory: initialized node ipu2_cma@95800000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x99000000, size 64 MiB
[    0.000000] Reserved memory: initialized node dsp1_cma@99000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x9d000000, size 32 MiB
[    0.000000] Reserved memory: initialized node ipu1_cma@9d000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x9f000000, size 8 MiB
[    0.000000] Reserved memory: initialized node dsp2_cma@9f000000, compatible id shared-dma-pool
[    0.000000] cma: Reserved 24 MiB at 0xde000000
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] DRA752 ES1.1
[    0.000000] PERCPU: Embedded 12 pages/cpu @ee9af000 s17792 r8192 d23168 u49152
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 390994
[    0.000000] Kernel command line: console=ttyO0,115200n8 earlyprintk rootwait  ip=:::::eth0:dhcp  root=/dev/nfs rw nfsroot=192.168.0.1:/home/tigtfarm07/NFS_exports/dra7xx-evm1/autofs/1d8e30535854dc371534f96e3c6d5488,nolock 
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 1356664K/1570816K available (6271K kernel code, 508K rwdata, 2240K rodata, 372K init, 266K bss, 25736K reserved, 188416K cma-reserved, 768000K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0858064   (8513 kB)
[    0.000000]       .init : 0xc0859000 - 0xc08b6000   ( 372 kB)
[    0.000000]       .data : 0xc08b6000 - 0xc09352c0   ( 509 kB)
[    0.000000]        .bss : 0xc0938000 - 0xc097ab78   ( 267 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] 	Additional per-CPU info printed with stalls.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] 	Offload RCU callbacks from all CPUs
[    0.000000] 	Offload RCU callbacks from CPUs: 0-1.
[    0.000000] OMAP clockevent source: timer1 at 32768 Hz
[    0.000000] clocksource 32k_counter: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 65535999984741ns
[    0.000000] OMAP clocksource: 32k_counter at 32768 Hz
[    0.000427] Architected cp15 timer(s) running at 6.14MHz (virt).
[    0.000457] clocksource arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x16af5adb9, max_idle_ns: 440795202250 ns
[    0.000463] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511023ns
[    0.000470] Switching to timer-based delay loop, resolution 162ns
[    0.001360] Console: colour dummy device 80x30
[    0.001486] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
[    0.001488] This ensures that you still see kernel messages. Please
[    0.001489] update your kernel commandline.
[    0.001502] Calibrating delay loop (skipped), value calculated using timer frequency.. 12.29 BogoMIPS (lpj=61475)
[    0.001506] pid_max: default: 32768 minimum: 301
[    0.001583] Security Framework initialized
[    0.001620] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.001626] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.002189] Initializing cgroup subsys blkio
[    0.002197] Initializing cgroup subsys memory
[    0.002221] Initializing cgroup subsys devices
[    0.002228] Initializing cgroup subsys freezer
[    0.002236] Initializing cgroup subsys perf_event
[    0.002278] CPU: Testing write buffer coherency: ok
[    0.002517] /cpus/cpu@0 missing clock-frequency property
[    0.002598] /cpus/cpu@1 missing clock-frequency property
[    0.002609] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.002653] Setting up static identity map for 0x80008280 - 0x800082f0
[    0.120957] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.121040] Brought up 2 CPUs
[    0.121054] SMP: Total of 2 processors activated (24.59 BogoMIPS).
[    0.121061] CPU: All CPU(s) started in SVC mode.
[    0.121513] devtmpfs: initialized
[    0.149180] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
[    0.149968] omap_hwmod: l3_main_2 using broken dt data from ocp
[    0.164029] omap_hwmod: tptc0 using broken dt data from edma-controller
[    0.164509] omap_hwmod: tptc1 using broken dt data from edma-controller
[    0.338569] clocksource jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.342242] pinctrl core: initialized pinctrl subsystem
[    0.343204] NET: Registered protocol family 16
[    0.345772] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.354459] OMAP GPIO hardware version 0.1
[    0.362174] irq: no irq domain found for /ocp/l4@4a000000/scm@2000/pinmux@1400 !
[    0.388931] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[    0.388942] hw-breakpoint: maximum watchpoint size is 8 bytes.
[    0.391765] omap4_sram_init:Unable to allocate sram needed to handle errata I688
[    0.391775] omap4_sram_init:Unable to get sram pool needed to handle errata I688
[    0.392434] OMAP DMA hardware revision 0.0
[    0.409403] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver
[    0.412466] omap-dma-engine 4a056000.dma-controller: OMAP DMA engine driver
[    0.413035] platform fixedregulator-sd: Driver reg-fixed-voltage requests probe deferral
[    0.418357] omap-iommu 40d01000.mmu: 40d01000.mmu registered
[    0.418619] omap-iommu 40d02000.mmu: 40d02000.mmu registered
[    0.418864] omap-iommu 58882000.mmu: 58882000.mmu registered
[    0.419116] omap-iommu 55082000.mmu: 55082000.mmu registered
[    0.419488] omap-iommu 41501000.mmu: 41501000.mmu registered
[    0.419750] omap-iommu 41502000.mmu: 41502000.mmu registered
[    0.420001] vgaarb: loaded
[    0.420424] SCSI subsystem initialized
[    0.421911] palmas 0-0058: IRQ missing: skipping irq request
[    0.441468] palmas 0-0058: Muxing GPIO 2e, PWM 0, LED 0
[    0.513681] pcf857x 0-0020: probed
[    0.514304] pcf857x 0-0021: probed
[    0.514450] omap_i2c 48070000.i2c: bus 0 rev0.12 at 400 kHz
[    0.531230] GPIO line 465 (vin6_sel_s0) hogged as output/low
[    0.531421] pcf857x 1-0026: probed
[    0.531580] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
[    0.532021] omap_i2c 48060000.i2c: bus 2 rev0.12 at 400 kHz
[    0.532308] pps_core: LinuxPPS API ver. 1 registered
[    0.532317] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.532346] PTP clock support registered
[    0.533009] omap-mailbox 48840000.mailbox: omap mailbox rev 0x400
[    0.533319] omap-mailbox 48842000.mailbox: omap mailbox rev 0x400
[    0.533623] Advanced Linux Sound Architecture Driver Initialized.
[    0.534366] Switched to clocksource arch_sys_counter
[    0.544551] NET: Registered protocol family 2
[    0.545253] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    0.545334] TCP bind hash table entries: 8192 (order: 5, 229376 bytes)
[    0.545623] TCP: Hash tables configured (established 8192 bind 8192)
[    0.545685] UDP hash table entries: 512 (order: 3, 32768 bytes)
[    0.545741] UDP-Lite hash table entries: 512 (order: 3, 32768 bytes)
[    0.545949] NET: Registered protocol family 1
[    0.546240] RPC: Registered named UNIX socket transport module.
[    0.546249] RPC: Registered udp transport module.
[    0.546256] RPC: Registered tcp transport module.
[    0.546263] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.547419] CPU PMU: Failed to parse /pmu/interrupt-affinity[0]
[    0.547454] hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
[    0.549458] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.549541] audit: initializing netlink subsys (disabled)
[    0.549576] audit: type=2000 audit(0.530:1): initialized
[    0.556198] VFS: Disk quotas dquot_6.6.0
[    0.556369] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.558508] NFS: Registering the id_resolver key type
[    0.558542] Key type id_resolver registered
[    0.558550] Key type id_legacy registered
[    0.558610] jffs2: version 2.2. (NAND) (SUMMARY)   2001-2006 Red Hat, Inc.
[    0.560591] NET: Registered protocol family 38
[    0.560698] bounce: pool size: 64 pages
[    0.560713] io scheduler noop registered
[    0.560727] io scheduler deadline registered
[    0.560879] io scheduler cfq registered (default)
[    0.564728] pinctrl-single 4a003400.pinmux: 281 pins at pa fc003400 size 1124
[    0.574576] dra7-pcie 51000000.pcie: PCI host bridge to bus 0000:00
[    0.574590] pci_bus 0000:00: root bus resource [io  0x1000-0xffff]
[    0.574600] pci_bus 0000:00: root bus resource [mem 0x20013000-0x2fffffff]
[    0.574612] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.574765] pci 0000:00:00.0: IOMMU is currently not supported for PCI
[    0.575026] PCI: bus0: Fast back to back transfers disabled
[    0.575470] pci 0000:01:00.0: IOMMU is currently not supported for PCI
[    0.575814] PCI: bus1: Fast back to back transfers disabled
[    0.575950] pci 0000:00:00.0: BAR 0: assigned [mem 0x20100000-0x201fffff]
[    0.575966] pci 0000:00:00.0: BAR 8: assigned [mem 0x20200000-0x202fffff]
[    0.575978] pci 0000:00:00.0: BAR 9: assigned [mem 0x20300000-0x203fffff pref]
[    0.575989] pci 0000:00:00.0: BAR 1: assigned [mem 0x20020000-0x2002ffff]
[    0.576002] pci 0000:00:00.0: BAR 7: assigned [io  0x1000-0x1fff]
[    0.576017] pci 0000:01:00.0: BAR 1: assigned [mem 0x20200000-0x2027ffff]
[    0.576037] pci 0000:01:00.0: BAR 6: assigned [mem 0x20300000-0x2033ffff pref]
[    0.576048] pci 0000:01:00.0: BAR 0: assigned [mem 0x20280000-0x2029ffff]
[    0.576067] pci 0000:01:00.0: BAR 3: assigned [mem 0x202a0000-0x202a3fff]
[    0.576086] pci 0000:01:00.0: BAR 2: assigned [io  0x1000-0x101f]
[    0.576106] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.576116] pci 0000:00:00.0:   bridge window [io  0x1000-0x1fff]
[    0.576128] pci 0000:00:00.0:   bridge window [mem 0x20200000-0x202fffff]
[    0.576138] pci 0000:00:00.0:   bridge window [mem 0x20300000-0x203fffff pref]
[    0.579925] OMAP DSS rev 6.1
[    0.580244] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dispc_component_ops)
[    0.580839] omapdss_dss 58000000.dss: bound 58040000.encoder (ops hdmi5_component_ops)
[    0.581749] platform encoder@1: Driver dra7evm-tpd12s015 requests probe deferral
[    0.582201] connector-hdmi connector@1: failed to find video source
[    0.582219] platform connector@1: Driver connector-hdmi requests probe deferral
[    0.585743] Serial: 8250/16550 driver, 10 ports, IRQ sharing enabled
[    0.588508] 4806a000.serial: ttyS0 at MMIO 0x4806a000 (irq = 299, base_baud = 3000000) is a 8250
[    1.662547] console [ttyS0] enabled
[    1.666661] 4806c000.serial: ttyS1 at MMIO 0x4806c000 (irq = 300, base_baud = 3000000) is a 8250
[    1.676287] 48020000.serial: ttyS2 at MMIO 0x48020000 (irq = 301, base_baud = 3000000) is a 8250
[    1.686280] [drm] Initialized drm 1.1.0 20060810
[    1.700726] brd: module loaded
[    1.708417] loop: module loaded
[    1.712651] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.723546] mousedev: PS/2 mouse device common for all mice
[    1.729154] i2c /dev entries driver
[    1.734581] omap_hsmmc 4809c000.mmc: Got CD GPIO
[    1.739413] omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
[    1.746235] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
[    1.753335] platform 4809c000.mmc: Driver omap_hsmmc requests probe deferral
[    1.760862] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr104 mode
[    1.767334] omap_hsmmc 480b4000.mmc: no pinctrl state for hs200_1_8v mode
[    1.774151] omap_hsmmc 480b4000.mmc: no pinctrl state for ddr50 mode
[    1.780537] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr50 mode
[    1.786920] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
[    1.793302] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
[    1.800000] evm_3v3_sw: supplied by sysen1
[    1.845119] omap_hsmmc 480d1000.mmc: no pinctrl state for sdr104 mode
[    1.851589] omap_hsmmc 480d1000.mmc: no pinctrl state for hs200_1_8v mode
[    1.858426] omap_hsmmc 480d1000.mmc: no pinctrl state for ddr50 mode
[    1.864810] omap_hsmmc 480d1000.mmc: no pinctrl state for sdr50 mode
[    1.871192] omap_hsmmc 480d1000.mmc: no pinctrl state for ddr_1_8v mode
[    1.888212] mmc0: MAN_BKOPS_EN bit is not set
[    1.896106] mmc0: new DDR MMC card at address 0001
[    1.901266] mmcblk0: mmc0:0001 MMC08G 7.25 GiB 
[    1.905933] mmcblk0boot0: mmc0:0001 MMC08G partition 1 8.00 MiB
[    1.911994] mmcblk0boot1: mmc0:0001 MMC08G partition 2 8.00 MiB
[    1.918716]  mmcblk0: p1 p2 p3
[    1.995125] omap-aes 4b500000.aes: OMAP AES hw accel rev: 3.3
[    2.001694] omap-aes 4b700000.aes: OMAP AES hw accel rev: 3.3
[    2.009016] omap-des 480a5000.des: OMAP DES hw accel rev: 2.2
[    2.015924] omap-sham 4b101000.sham: hw accel on OMAP rev 4.3
[    2.026077] davinci-mcasp 48468000.mcasp: ERRATA i868 workaround is enabled
[    2.035132] davinci-mcasp 4847c000.mcasp: ERRATA i868 workaround is enabled
[    2.042544] Initializing XFRM netlink socket
[    2.046882] NET: Registered protocol family 17
[    2.051375] NET: Registered protocol family 15
[    2.055925] Key type dns_resolver registered
[    2.060338] omap_voltage_late_init: Voltage driver support not added
[    2.066734] sr_dev_init: Unable to get voltage domain pointer for VDD core
[    2.073638] sr_dev_init: Unable to get voltage domain pointer for VDD mpu
[    2.080738] Power Management for TI OMAP4+ devices.
[    2.085863] ThumbEE CPU extension supported.
[    2.090164] Registering SWP/SWPB emulation handler
[    2.094984] SmartReflex Class3 initialized
[    2.100743] dmm 4e000000.dmm: workaround for errata i878 in use
[    2.108418] dmm 4e000000.dmm: initialized all PAT entries
[    2.114210] platform omapdrm.0: Driver omapdrm requests probe deferral
[    2.123162] omap_hsmmc 4809c000.mmc: Got CD GPIO
[    2.128009] omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
[    2.134830] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
[    2.196401] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    2.203044] [drm] No driver support for vblank timestamp query.
[    2.209023] omapdrm omapdrm.0: No connectors reported connected with modes
[    2.215933] [drm] Cannot find any crtc or sizes - going 1024x768
[    2.227640] [drm] Enabling DMM ywrap scrolling
[    2.239535] Console: switching to colour frame buffer device 128x48
[    2.251305] omapdrm omapdrm.0: fb0: omapdrm frame buffer device
[    2.257253] omapdrm omapdrm.0: registered panic notifier
[    2.274429] [drm] Initialized omapdrm 1.0.0 20110917 on minor 0
[    2.280400] ====================================== deferred_probe_initcalll
[    2.334387] davinci_mdio 48485000.mdio: davinci mdio revision 1.6
[    2.340513] davinci_mdio 48485000.mdio: detected phy mask fffffff3
[    2.344381] mmc2: host does not support reading read-only switch, assuming write-enable
[    2.349716] mmc2: new high speed SDHC card at address e624
[    2.354396] mmcblk1: mmc2:e624 SU04G 3.69 GiB 
[    2.362506]  mmcblk1: p1 p2 p3
[    2.372593] libphy: 48485000.mdio: probed
[    2.376626] davinci_mdio 48485000.mdio: phy[2]: device 48485000.mdio:02, driver unknown
[    2.384668] davinci_mdio 48485000.mdio: phy[3]: device 48485000.mdio:03, driver unknown
[    2.393389] cpsw 48484000.ethernet: Detected MACID = b4:99:4c:0b:e4:e6
[    2.400896] cpsw 48484000.ethernet: cpsw: Detected MACID = b4:99:4c:0b:e4:e7
[    2.408583] hctosys: unable to open rtc device (rtc0)
[    2.413661] sr_init: No PMIC hook to init smartreflex
[    2.418903] sr_init: platform driver register failed for SR
[    2.441783] net eth0: initializing cpsw version 1.15 (0)
[    2.528312] net eth0: phy found : id is : 0x20005c7a
[    6.531286] cpsw 48484000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[    6.554382] Sending DHCP requests ., OK
[    6.624439] IP-Config: Got DHCP answer from 192.168.0.1, my address is 192.168.0.192
[    6.632426] IP-Config: Complete:
[    6.635674]      device=eth0, hwaddr=b4:99:4c:0b:e4:e6, ipaddr=192.168.0.192, mask=255.255.255.0, gw=192.168.0.1
[    6.645895]      host=192.168.0.192, domain=ti.com, nis-domain=(none)
[    6.652364]      bootserver=192.168.0.1, rootserver=192.168.0.1, rootpath=
[    6.659095]      nameserver0=192.0.2.2, nameserver1=192.0.2.3
[    6.665282] ldousb: disabling
[    6.668549] vmmcwl_fixed: disabling
[    6.672054] aic_dvdd: disabling
[    6.675417] ALSA device list:
[    6.678397]   No soundcards found.
[    6.687614] VFS: Mounted root (nfs filesystem) on device 0:15.
[    6.693779] devtmpfs: mounted
[    6.697044] Freeing unused kernel memory: 372K (c0859000 - c08b6000)

INIT: version 2.88 booting

Starting udev
[    7.129889] udevd[175]: starting version 182
[    7.329630] omap-rproc 58820000.ipu: assigned reserved memory node ipu1_cma@9d000000
[    7.349436]  remoteproc0: 58820000.ipu is available
[    7.358961]  remoteproc0: Note: remoteproc is still under development and considered experimental.
[    7.431205]  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.452181]  remoteproc0: Direct firmware load for dra7-ipu1-fw.xem4 failed with error -2
[    7.456683] omap-rproc 55020000.ipu: assigned reserved memory node ipu2_cma@95800000
[    7.471645]  remoteproc1: 55020000.ipu is available
[    7.471649]  remoteproc1: Note: remoteproc is still under development and considered experimental.
[    7.471653]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.480262] omap-rproc 40800000.dsp: assigned reserved memory node dsp1_cma@99000000
[    7.510612]  remoteproc2: 40800000.dsp is available
[    7.510618]  remoteproc2: Note: remoteproc is still under development and considered experimental.
[    7.510622]  remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.514543] omap-rproc 41000000.dsp: assigned reserved memory node dsp2_cma@9f000000
[    7.523301]  remoteproc3: 41000000.dsp is available
[    7.523306]  remoteproc3: Note: remoteproc is still under development and considered experimental.
[    7.523309]  remoteproc3: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.614060]  remoteproc0: Falling back to user helper
[    7.672048] aic_dvdd: supplied by evm_3v3_sw
[    7.736112] omap_rng 48090000.rng: OMAP Random Number Generator ver. 20
[    8.067185] media: Linux media interface: v0.10
[    8.216475] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc as rtc0
[    8.217206] Linux video capture interface: v2.00
[    8.276707] random: nonblocking pool is initialized
[    8.394957] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    8.420281] platform 48880000.omap_dwc3_1: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    8.423788] ov1063x 1-0037: Failed writing register 0x0103!
[    8.423807] ov1063x: probe of 1-0037 failed with error -121
[    8.488870]  remoteproc0: failed to load dra7-ipu1-fw.xem4
[    8.729862] platform 488c0000.omap_dwc3_2: Driver omap-dwc3 requests probe deferral
[    8.733069] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    8.733072] e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
[    8.733178] e1000e 0000:01:00.0: enabling device (0140 -> 0142)
[    8.733435] e1000e 0000:01:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    8.750383] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[    8.750685] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    8.750692] platform 48880000.omap_dwc3_1: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    8.779935] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[    8.780067] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    8.780073] platform 48880000.omap_dwc3_1: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    8.951061] CAN device driver interface
[    8.963296] e1000e 0000:01:00.0 eth2: registered PHC clock
[    8.963304] e1000e 0000:01:00.0 eth2: (PCI Express:2.5GT/s:Width x1) 68:05:ca:36:2b:25
[    8.963311] e1000e 0000:01:00.0 eth2: Intel(R) PRO/1000 Network Connection
[    8.966445] e1000e 0000:01:00.0 eth2: MAC: 3, PHY: 8, PBA No: E46981-008
[    9.024825] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[    9.027031] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    9.027039] platform 48880000.omap_dwc3_1: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    9.287323]  remoteproc2: Direct firmware load for dra7-dsp1-fw.xe66 failed with error -2
[    9.287327]  remoteproc2: Falling back to user helper
[    9.308265] omap-dwc3 48880000.omap_dwc3_1: **** dwc3_omap_probe done
[    9.341969] platform 488c0000.omap_dwc3_2: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    9.357153] vpe 489d0000.vpe: loading firmware vpdma-1b8.bin
[    9.363840]  remoteproc1: registered virtio0 (type 7)
[    9.390936] omap-dwc3 488c0000.omap_dwc3_2: **** dwc3_omap_probe done
[    9.411821] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    9.487056] input: gpio_keys as /devices/platform/gpio_keys/input/input0
[    9.530380] asoc-simple-card sound@0: tlv320aic3x-hifi <-> 48468000.mcasp mapping ok
[    9.572735] c_can_platform 4ae3c000.can: c_can_platform device registered (regs=fce3c000, irq=349)
[    9.585025] vip 48970000.vip: loading firmware vpdma-1b8.bin
[    9.592896] ahci 4a140000.sata: SSS flag set, parallel bus scan disabled
[    9.599650] ahci 4a140000.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[    9.608289] ahci 4a140000.sata: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part ccc apst 
[    9.703388] scsi host0: ahci
[    9.763672] omap-hdmi-audio omap-hdmi-audio.0.auto: snd-soc-dummy-dai <-> 58040000.encoder mapping ok
[    9.803153] ata1: SATA max UDMA/133 mmio [mem 0x4a140000-0x4a1410ff] port 0x100 irq 336
[   10.164442] ata1: SATA link down (SStatus 0 SControl 300)
[   10.642315]  remoteproc2: failed to load dra7-dsp1-fw.xe66
[   10.659698]  remoteproc3: Direct firmware load for dra7-dsp2-fw.xe66 failed with error -2
[   10.671669]  remoteproc3: Falling back to user helper
[   10.811525]  remoteproc1: powering up 55020000.ipu
[   10.820600] m25p80 spi32766.0: s25fl256s1 (32768 Kbytes)
[   10.820686] 10 ofpart partitions found on MTD device spi32766.0
[   10.820693] Creating 10 MTD partitions on "spi32766.0":
[   10.820702] 0x000000000000-0x000000010000 : "QSPI.SPL"
[   10.886395] 0x000000010000-0x000000020000 : "QSPI.SPL.backup1"
[   10.895608]  remoteproc3: failed to load dra7-dsp2-fw.xe66
[   10.909877] 0x000000020000-0x000000030000 : "QSPI.SPL.backup2"
[   10.912583] 0x000000030000-0x000000040000 : "QSPI.SPL.backup3"
[   10.913546] 0x000000040000-0x000000140000 : "QSPI.u-boot"
[   10.914433] vip 48970000.vip: VPDMA firmware loaded
[   10.914670] vpe 489d0000.vpe: Device registered as /dev/video0
[   10.938439] 0x000000140000-0x0000001c0000 : "QSPI.u-boot-spl-os"
[   10.962444] 0x0000001c0000-0x0000001d0000 : "QSPI.u-boot-env"
[   11.011549] 0x0000001d0000-0x0000001e0000 : "QSPI.u-boot-env.backup1"
[   11.071277] 0x0000001e0000-0x0000009e0000 : "QSPI.kernel"
[   11.080616] 0x0000009e0000-0x000002000000 : "QSPI.file-system"
[   11.415621] EXT4-fs (mmcblk0p3): mounted filesystem without journal. Opts: (null)
[   11.439508] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   11.476702]  remoteproc1: Booting fw image dra7-ipu2-fw.xem4, size 3480916
[   11.491518] EXT4-fs (mmcblk1p3): mounted filesystem without journal. Opts: (null)
[   11.495115] EXT4-fs (mmcblk1p2): warning: maximal mount count reached, running e2fsck is recommended
[   11.505950] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)
[   11.536011] FAT-fs (mmcblk0p2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   11.641063] FAT-fs (mmcblk1p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   11.690531] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
[   11.894821] dwc3 48890000.usb: **** dwc3_probe done
[   11.972740]  remoteproc1: remote processor 55020000.ipu is now up
[   11.999719] virtio_rpmsg_bus virtio0: rpmsg host is online
[   12.003008] virtio_rpmsg_bus virtio0: creating channel rpmsg-rpc addr 0x3b
[   12.085055] rpmsg_rpc rpmsg0: probing service rpmsg-dce with src 1024 dst 59
[   12.092778] rpmsg_rpc rpmsg0: published functions = 8
[   12.387531] dwc3 488d0000.usb: **** dwc3_probe done
[   12.555405] usbcore: registered new interface driver usbfs
[   12.561001] usbcore: registered new interface driver hub
[   12.566496] usbcore: registered new device driver usb
[   12.619632] dwc3 48890000.usb: otg: primary host xhci-hcd.1.auto registered
[   12.626635] dwc3 48890000.usb: otg: shared host xhci-hcd.1.auto registered
[   12.633543] dwc3 48890000.usb: otg: can't start till gadget registers
[   12.640118] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[   12.645652] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 1
[   12.653905] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[   12.662779] xhci-hcd xhci-hcd.2.auto: irq 463, io mem 0x488d0000
[   12.668985] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[   12.681600] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   12.688857] usb usb1: Product: xHCI Host Controller
[   12.693757] usb usb1: Manufacturer: Linux 4.1.10-rt10-02639-gd63d0be-dirty xhci-hcd
[   12.701448] usb usb1: SerialNumber: xhci-hcd.2.auto
[   12.707274] hub 1-0:1.0: USB hub found
[   12.711077] hub 1-0:1.0: 1 port detected
[   12.715501] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[   12.721021] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 2
[   12.728804] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[   12.737061] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[   12.743880] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   12.751136] usb usb2: Product: xHCI Host Controller
[   12.756039] usb usb2: Manufacturer: Linux 4.1.10-rt10-02639-gd63d0be-dirty xhci-hcd
[   12.763727] usb usb2: SerialNumber: xhci-hcd.2.auto
[   12.769500] hub 2-0:1.0: USB hub found
[   12.773298] hub 2-0:1.0: 1 port detected
bootlogd: cannot allocate pseudo tty: No such file or directory
Starting random number generator daemon.
[   13.034435] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[   13.176262] usb 1-1: New USB device found, idVendor=154b, idProduct=007a
[   13.183002] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   13.190859] usb 1-1: Product: USB 2.0 FD
[   13.194810] usb 1-1: Manufacturer: PNY Technologies
[   13.199717] usb 1-1: SerialNumber: AEC12H25YE11003156
[   13.209498] usb 1-1: ep 0x81 - rounding interval to 128 microframes, ep desc says 255 microframes
[   13.218598] usb 1-1: ep 0x2 - rounding interval to 128 microframes, ep desc says 255 microframes
[   13.280307] usb-storage 1-1:1.0: USB Mass Storage device detected
[   13.287194] scsi host1: usb-storage 1-1:1.0
[   13.293029] usbcore: registered new interface driver usb-storage

Re: Alternative approach to solve the deferred probe

[Grygorii Strashko]

Hi Russell,

On 10/21/2015 09:28 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
>> But I worry a bit (and that my main point) about these few additional
>> rounds of deferred device probing which I have right now and which allows
>> some of drivers to finish, finally, their probes successfully.
>> With proposed change I'll get more messages in boot log, but some of
>> them will belong to drivers which have been probed successfully and so,
>> they will be not really useful.
> 
> Then you haven't properly understood my proposal.
> 
> I want to get rid of all the "X deferred its probing" messages up until
> the point that we set the "please report deferred probes" flag.
> 
> That _should_ mean that all the deferred probing that goes on becomes
> _totally_ silent and becomes hidden (unless you really want to see it,
> in which case we can make a debug option which turns it on) up until
> we're at the point where we want to enter userspace.
> 
> At that point, we then report into the kernel log which devices are
> still deferring and, via appropriately placed dev_warn_deferred(),
> the reasons why the devices are being deferred.
> 
> So, gone will be all the messages earlier in the log about device X
> not having a GPIO/clock/whatever because the device providing the
> GPIO/clock/whatever hasn't been probed.
> 
> If everything is satisfied by the time we run this last round (again,
> I'm not using a three line sentence to describe exactly what I mean,
> I'm sure you know by now... oops, I just did) then the kernel will
> report nothing about any deferrals.  That's _got_ to be an improvement.

Sorry Master, but you really don't need to spend so much time typing the
same things three times  - I understand what are you trying to do :(

I did my comments with assumption that it's not officially prohibited/deprecated
to register drivers (and execute probes) from late_initcall() layer
(just recommended) and there are still bunch of drivers which are doing this.
Now I see that it's not a recommendation any more, and deferred_probe_initcall()
might be a good place to activate driver_deferred_probe_report if goal is to
identify and fix such drivers.

Sorry for your time.

> 
>>
>> As result, I think, the most important thing is to identify (or create)
>> some point during kernel boot when it will be possible to say that all
>> built-in drivers (at least) finish their probes 100% (done or defer).
>>
>> Might be do_initcalls() can be updated (smth like this):
>> static void __init do_initcalls(void)
>> {
>> 	int level;
>>
>> 	for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
>> 		do_initcall_level(level);
>>
>> +	wait_for_device_probe();
>> +	/* Now one final round, reporting any devices that remain deferred */
>> +	driver_deferred_probe_report = true;
>> +	driver_deferred_probe_trigger();
>> +	wait_for_device_probe();
>> }
>>
>> Also, in my opinion, it will be useful if this debugging feature will be
>> optional.
> 
> I wonder why you want it optional... so I'm going to guess and cover
> both cases I can think of below to head off another round of reply on
> this point (sorry if this sucks eggs.)
> 
> I don't see it as being optional, because it's going to be cheap to run
> in the case of a system which has very few or no errors - which is what
> you should have for production systems, right?
> 

Also, I've spend some time today testing your proposal - hope you'll find results
useful.

I've applied truncated version of your patch (diff below) on TI's 4.1 kernel and
run few tests (log is below) on dra7-evm/am43xx-gpevm - K4.1 is not far away from LKML,
so I assume this test is valid. Overall boot process consists from two stages:
kernel boot and modules loading. 

My Changes:
 - only really_probe() modified to show deferred device/drivers 

>From the log I can see additional messages in log when modules are loading,
because driver_deferred_probe_report is still true - dwc3 probes were deferred,
but then finally succeeded.

So, as you've mentioned, it seems a good thing to deactivate driver_deferred_probe_report and
provide user with ability to turn it on again (and probably re-trigger deferred
device probing).

I've found no issues during Kernel boot (built-in) time, new messages are displayed only
if probe is failed for some drivers:
[    3.219700] ====================================== deferred_probe_initcalll
[    3.226820] platform omapdrm.0: Driver omapdrm requests probe deferral
[    3.233378] platform omapdrm.0: deferring probe: ==== Driver omapdrm requests probe deferral
[    3.242084] dra7evm-tpd12s015 encoder@1: failed to parse CT CP HPD gpio
[    3.248737] platform encoder@1: Driver dra7evm-tpd12s015 requests probe deferral
[    3.256168] platform encoder@1: deferring probe: ==== Driver dra7evm-tpd12s015 requests probe deferral
[    3.265763] connector-hdmi connector@1: failed to find video source
[    3.272067] platform connector@1: Driver connector-hdmi requests probe deferral
[    3.279410] platform connector@1: deferring probe: ==== Driver connector-hdmi requests probe deferral 
^^ above drivers will be deferred forever

Thanks.
-- 
regards,
-grygorii
S/ILKP

*************** [TEST CODE] ***********
---
 drivers/base/dd.c | 33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index e7d2545..d61fa47 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -129,6 +129,27 @@ void driver_deferred_probe_del(struct device *dev)
 	mutex_unlock(&deferred_probe_mutex);
 }
 
+static bool driver_deferred_probe_report;
+
+/**
+ * dev_warn_deferred() - report why a probe has been deferred
+ */
+void dev_warn_deferred(struct device *dev, const char *fmt, ...)
+{
+	if (driver_deferred_probe_report) {
+		struct va_format vaf;
+		va_list ap;
+
+		va_start(ap, fmt);
+		vaf.fmt = fmt;
+		vaf.va = &ap;
+
+		dev_err(dev, "deferring probe: %pV", &vaf);
+		va_end(ap);
+	}
+}
+EXPORT_SYMBOL_GPL(dev_warn_deferred);
+
 static bool driver_deferred_probe_enable = false;
 /**
  * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
@@ -188,6 +209,15 @@ static int deferred_probe_initcall(void)
 	driver_deferred_probe_trigger();
 	/* Sort as many dependencies as possible before exiting initcalls */
 	flush_workqueue(deferred_wq);
+
+	pr_err("====================================== deferred_probe_initcalll\n");
+
+	/* Now one final round, reporting any devices that remain deferred */
+	driver_deferred_probe_report = true;
+	driver_deferred_probe_trigger();
+	/* Sort as many dependencies as possible before exiting initcalls */
+	flush_workqueue(deferred_wq);
+
 	return 0;
 }
 late_initcall(deferred_probe_initcall);
@@ -342,7 +372,8 @@ probe_failed:
 	switch (ret) {
 	case -EPROBE_DEFER:
 		/* Driver requested deferred probing */
-		dev_dbg(dev, "Driver %s requests probe deferral\n", drv->name);
+		dev_err(dev, "Driver %s requests probe deferral\n", drv->name);
+		dev_warn_deferred(dev, "==== Driver %s requests probe deferral\n", drv->name);
 		driver_deferred_probe_add(dev);
 		/* Did a trigger occur while probing? Need to re-trigger if yes */
 		if (local_trigger_count != atomic_read(&deferred_trigger_count))
-- 
2.6.2


*************** [BOOT LOG] ***********
Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.1.10-rt10-02639-gd63d0be-dirty (lcpdbld@dflsdit-build06.dal.design.ti.com) (gcc version 4.9.3 20150413 (prerelease) (Linaro GCC 4.9-2015.05) ) #1 SMP PREEMPT RT Thu Oct 22 05:11:58 CDT 2015
[    0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] Machine model: TI DRA742
[    0.000000] Reserved memory: created CMA memory pool at 0x95800000, size 56 MiB
[    0.000000] Reserved memory: initialized node ipu2_cma@95800000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x99000000, size 64 MiB
[    0.000000] Reserved memory: initialized node dsp1_cma@99000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x9d000000, size 32 MiB
[    0.000000] Reserved memory: initialized node ipu1_cma@9d000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x9f000000, size 8 MiB
[    0.000000] Reserved memory: initialized node dsp2_cma@9f000000, compatible id shared-dma-pool
[    0.000000] cma: Reserved 24 MiB at 0xde000000
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] DRA752 ES1.1
[    0.000000] PERCPU: Embedded 12 pages/cpu @ee9af000 s17792 r8192 d23168 u49152
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 390994
[    0.000000] Kernel command line: console=ttyO0,115200n8 earlyprintk rootwait  ip=:::::eth0:dhcp  root=/dev/nfs rw nfsroot=192.168.0.1:/home/tigtfarm07/NFS_exports/dra7xx-evm1/autofs/1d8e30535854dc371534f96e3c6d5488,nolock 
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 1356664K/1570816K available (6271K kernel code, 508K rwdata, 2240K rodata, 372K init, 266K bss, 25736K reserved, 188416K cma-reserved, 768000K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0858064   (8513 kB)
[    0.000000]       .init : 0xc0859000 - 0xc08b6000   ( 372 kB)
[    0.000000]       .data : 0xc08b6000 - 0xc09352c0   ( 509 kB)
[    0.000000]        .bss : 0xc0938000 - 0xc097ab78   ( 267 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] 	Additional per-CPU info printed with stalls.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] 	Offload RCU callbacks from all CPUs
[    0.000000] 	Offload RCU callbacks from CPUs: 0-1.
[    0.000000] OMAP clockevent source: timer1 at 32768 Hz
[    0.000000] clocksource 32k_counter: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 65535999984741ns
[    0.000000] OMAP clocksource: 32k_counter at 32768 Hz
[    0.000427] Architected cp15 timer(s) running at 6.14MHz (virt).
[    0.000457] clocksource arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x16af5adb9, max_idle_ns: 440795202250 ns
[    0.000463] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511023ns
[    0.000470] Switching to timer-based delay loop, resolution 162ns
[    0.001360] Console: colour dummy device 80x30
[    0.001486] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
[    0.001488] This ensures that you still see kernel messages. Please
[    0.001489] update your kernel commandline.
[    0.001502] Calibrating delay loop (skipped), value calculated using timer frequency.. 12.29 BogoMIPS (lpj=61475)
[    0.001506] pid_max: default: 32768 minimum: 301
[    0.001583] Security Framework initialized
[    0.001620] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.001626] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.002189] Initializing cgroup subsys blkio
[    0.002197] Initializing cgroup subsys memory
[    0.002221] Initializing cgroup subsys devices
[    0.002228] Initializing cgroup subsys freezer
[    0.002236] Initializing cgroup subsys perf_event
[    0.002278] CPU: Testing write buffer coherency: ok
[    0.002517] /cpus/cpu@0 missing clock-frequency property
[    0.002598] /cpus/cpu@1 missing clock-frequency property
[    0.002609] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.002653] Setting up static identity map for 0x80008280 - 0x800082f0
[    0.120957] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.121040] Brought up 2 CPUs
[    0.121054] SMP: Total of 2 processors activated (24.59 BogoMIPS).
[    0.121061] CPU: All CPU(s) started in SVC mode.
[    0.121513] devtmpfs: initialized
[    0.149180] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
[    0.149968] omap_hwmod: l3_main_2 using broken dt data from ocp
[    0.164029] omap_hwmod: tptc0 using broken dt data from edma-controller
[    0.164509] omap_hwmod: tptc1 using broken dt data from edma-controller
[    0.338569] clocksource jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.342242] pinctrl core: initialized pinctrl subsystem
[    0.343204] NET: Registered protocol family 16
[    0.345772] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.354459] OMAP GPIO hardware version 0.1
[    0.362174] irq: no irq domain found for /ocp/l4@4a000000/scm@2000/pinmux@1400 !
[    0.388931] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[    0.388942] hw-breakpoint: maximum watchpoint size is 8 bytes.
[    0.391765] omap4_sram_init:Unable to allocate sram needed to handle errata I688
[    0.391775] omap4_sram_init:Unable to get sram pool needed to handle errata I688
[    0.392434] OMAP DMA hardware revision 0.0
[    0.409403] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver
[    0.412466] omap-dma-engine 4a056000.dma-controller: OMAP DMA engine driver
[    0.413035] platform fixedregulator-sd: Driver reg-fixed-voltage requests probe deferral
[    0.418357] omap-iommu 40d01000.mmu: 40d01000.mmu registered
[    0.418619] omap-iommu 40d02000.mmu: 40d02000.mmu registered
[    0.418864] omap-iommu 58882000.mmu: 58882000.mmu registered
[    0.419116] omap-iommu 55082000.mmu: 55082000.mmu registered
[    0.419488] omap-iommu 41501000.mmu: 41501000.mmu registered
[    0.419750] omap-iommu 41502000.mmu: 41502000.mmu registered
[    0.420001] vgaarb: loaded
[    0.420424] SCSI subsystem initialized
[    0.421911] palmas 0-0058: IRQ missing: skipping irq request
[    0.441468] palmas 0-0058: Muxing GPIO 2e, PWM 0, LED 0
[    0.513681] pcf857x 0-0020: probed
[    0.514304] pcf857x 0-0021: probed
[    0.514450] omap_i2c 48070000.i2c: bus 0 rev0.12 at 400 kHz
[    0.531230] GPIO line 465 (vin6_sel_s0) hogged as output/low
[    0.531421] pcf857x 1-0026: probed
[    0.531580] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
[    0.532021] omap_i2c 48060000.i2c: bus 2 rev0.12 at 400 kHz
[    0.532308] pps_core: LinuxPPS API ver. 1 registered
[    0.532317] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.532346] PTP clock support registered
[    0.533009] omap-mailbox 48840000.mailbox: omap mailbox rev 0x400
[    0.533319] omap-mailbox 48842000.mailbox: omap mailbox rev 0x400
[    0.533623] Advanced Linux Sound Architecture Driver Initialized.
[    0.534366] Switched to clocksource arch_sys_counter
[    0.544551] NET: Registered protocol family 2
[    0.545253] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    0.545334] TCP bind hash table entries: 8192 (order: 5, 229376 bytes)
[    0.545623] TCP: Hash tables configured (established 8192 bind 8192)
[    0.545685] UDP hash table entries: 512 (order: 3, 32768 bytes)
[    0.545741] UDP-Lite hash table entries: 512 (order: 3, 32768 bytes)
[    0.545949] NET: Registered protocol family 1
[    0.546240] RPC: Registered named UNIX socket transport module.
[    0.546249] RPC: Registered udp transport module.
[    0.546256] RPC: Registered tcp transport module.
[    0.546263] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.547419] CPU PMU: Failed to parse /pmu/interrupt-affinity[0]
[    0.547454] hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
[    0.549458] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.549541] audit: initializing netlink subsys (disabled)
[    0.549576] audit: type=2000 audit(0.530:1): initialized
[    0.556198] VFS: Disk quotas dquot_6.6.0
[    0.556369] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.558508] NFS: Registering the id_resolver key type
[    0.558542] Key type id_resolver registered
[    0.558550] Key type id_legacy registered
[    0.558610] jffs2: version 2.2. (NAND) (SUMMARY)   2001-2006 Red Hat, Inc.
[    0.560591] NET: Registered protocol family 38
[    0.560698] bounce: pool size: 64 pages
[    0.560713] io scheduler noop registered
[    0.560727] io scheduler deadline registered
[    0.560879] io scheduler cfq registered (default)
[    0.564728] pinctrl-single 4a003400.pinmux: 281 pins at pa fc003400 size 1124
[    0.574576] dra7-pcie 51000000.pcie: PCI host bridge to bus 0000:00
[    0.574590] pci_bus 0000:00: root bus resource [io  0x1000-0xffff]
[    0.574600] pci_bus 0000:00: root bus resource [mem 0x20013000-0x2fffffff]
[    0.574612] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.574765] pci 0000:00:00.0: IOMMU is currently not supported for PCI
[    0.575026] PCI: bus0: Fast back to back transfers disabled
[    0.575470] pci 0000:01:00.0: IOMMU is currently not supported for PCI
[    0.575814] PCI: bus1: Fast back to back transfers disabled
[    0.575950] pci 0000:00:00.0: BAR 0: assigned [mem 0x20100000-0x201fffff]
[    0.575966] pci 0000:00:00.0: BAR 8: assigned [mem 0x20200000-0x202fffff]
[    0.575978] pci 0000:00:00.0: BAR 9: assigned [mem 0x20300000-0x203fffff pref]
[    0.575989] pci 0000:00:00.0: BAR 1: assigned [mem 0x20020000-0x2002ffff]
[    0.576002] pci 0000:00:00.0: BAR 7: assigned [io  0x1000-0x1fff]
[    0.576017] pci 0000:01:00.0: BAR 1: assigned [mem 0x20200000-0x2027ffff]
[    0.576037] pci 0000:01:00.0: BAR 6: assigned [mem 0x20300000-0x2033ffff pref]
[    0.576048] pci 0000:01:00.0: BAR 0: assigned [mem 0x20280000-0x2029ffff]
[    0.576067] pci 0000:01:00.0: BAR 3: assigned [mem 0x202a0000-0x202a3fff]
[    0.576086] pci 0000:01:00.0: BAR 2: assigned [io  0x1000-0x101f]
[    0.576106] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.576116] pci 0000:00:00.0:   bridge window [io  0x1000-0x1fff]
[    0.576128] pci 0000:00:00.0:   bridge window [mem 0x20200000-0x202fffff]
[    0.576138] pci 0000:00:00.0:   bridge window [mem 0x20300000-0x203fffff pref]
[    0.579925] OMAP DSS rev 6.1
[    0.580244] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dispc_component_ops)
[    0.580839] omapdss_dss 58000000.dss: bound 58040000.encoder (ops hdmi5_component_ops)
[    0.581749] platform encoder@1: Driver dra7evm-tpd12s015 requests probe deferral
[    0.582201] connector-hdmi connector@1: failed to find video source
[    0.582219] platform connector@1: Driver connector-hdmi requests probe deferral
[    0.585743] Serial: 8250/16550 driver, 10 ports, IRQ sharing enabled
[    0.588508] 4806a000.serial: ttyS0 at MMIO 0x4806a000 (irq = 299, base_baud = 3000000) is a 8250
[    1.662547] console [ttyS0] enabled
[    1.666661] 4806c000.serial: ttyS1 at MMIO 0x4806c000 (irq = 300, base_baud = 3000000) is a 8250
[    1.676287] 48020000.serial: ttyS2 at MMIO 0x48020000 (irq = 301, base_baud = 3000000) is a 8250
[    1.686280] [drm] Initialized drm 1.1.0 20060810
[    1.700726] brd: module loaded
[    1.708417] loop: module loaded
[    1.712651] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.723546] mousedev: PS/2 mouse device common for all mice
[    1.729154] i2c /dev entries driver
[    1.734581] omap_hsmmc 4809c000.mmc: Got CD GPIO
[    1.739413] omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
[    1.746235] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
[    1.753335] platform 4809c000.mmc: Driver omap_hsmmc requests probe deferral
[    1.760862] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr104 mode
[    1.767334] omap_hsmmc 480b4000.mmc: no pinctrl state for hs200_1_8v mode
[    1.774151] omap_hsmmc 480b4000.mmc: no pinctrl state for ddr50 mode
[    1.780537] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr50 mode
[    1.786920] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
[    1.793302] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
[    1.800000] evm_3v3_sw: supplied by sysen1
[    1.845119] omap_hsmmc 480d1000.mmc: no pinctrl state for sdr104 mode
[    1.851589] omap_hsmmc 480d1000.mmc: no pinctrl state for hs200_1_8v mode
[    1.858426] omap_hsmmc 480d1000.mmc: no pinctrl state for ddr50 mode
[    1.864810] omap_hsmmc 480d1000.mmc: no pinctrl state for sdr50 mode
[    1.871192] omap_hsmmc 480d1000.mmc: no pinctrl state for ddr_1_8v mode
[    1.888212] mmc0: MAN_BKOPS_EN bit is not set
[    1.896106] mmc0: new DDR MMC card at address 0001
[    1.901266] mmcblk0: mmc0:0001 MMC08G 7.25 GiB 
[    1.905933] mmcblk0boot0: mmc0:0001 MMC08G partition 1 8.00 MiB
[    1.911994] mmcblk0boot1: mmc0:0001 MMC08G partition 2 8.00 MiB
[    1.918716]  mmcblk0: p1 p2 p3
[    1.995125] omap-aes 4b500000.aes: OMAP AES hw accel rev: 3.3
[    2.001694] omap-aes 4b700000.aes: OMAP AES hw accel rev: 3.3
[    2.009016] omap-des 480a5000.des: OMAP DES hw accel rev: 2.2
[    2.015924] omap-sham 4b101000.sham: hw accel on OMAP rev 4.3
[    2.026077] davinci-mcasp 48468000.mcasp: ERRATA i868 workaround is enabled
[    2.035132] davinci-mcasp 4847c000.mcasp: ERRATA i868 workaround is enabled
[    2.042544] Initializing XFRM netlink socket
[    2.046882] NET: Registered protocol family 17
[    2.051375] NET: Registered protocol family 15
[    2.055925] Key type dns_resolver registered
[    2.060338] omap_voltage_late_init: Voltage driver support not added
[    2.066734] sr_dev_init: Unable to get voltage domain pointer for VDD core
[    2.073638] sr_dev_init: Unable to get voltage domain pointer for VDD mpu
[    2.080738] Power Management for TI OMAP4+ devices.
[    2.085863] ThumbEE CPU extension supported.
[    2.090164] Registering SWP/SWPB emulation handler
[    2.094984] SmartReflex Class3 initialized
[    2.100743] dmm 4e000000.dmm: workaround for errata i878 in use
[    2.108418] dmm 4e000000.dmm: initialized all PAT entries
[    2.114210] platform omapdrm.0: Driver omapdrm requests probe deferral
[    2.123162] omap_hsmmc 4809c000.mmc: Got CD GPIO
[    2.128009] omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
[    2.134830] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
[    2.196401] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    2.203044] [drm] No driver support for vblank timestamp query.
[    2.209023] omapdrm omapdrm.0: No connectors reported connected with modes
[    2.215933] [drm] Cannot find any crtc or sizes - going 1024x768
[    2.227640] [drm] Enabling DMM ywrap scrolling
[    2.239535] Console: switching to colour frame buffer device 128x48
[    2.251305] omapdrm omapdrm.0: fb0: omapdrm frame buffer device
[    2.257253] omapdrm omapdrm.0: registered panic notifier
[    2.274429] [drm] Initialized omapdrm 1.0.0 20110917 on minor 0
[    2.280400] ====================================== deferred_probe_initcalll
[    2.334387] davinci_mdio 48485000.mdio: davinci mdio revision 1.6
[    2.340513] davinci_mdio 48485000.mdio: detected phy mask fffffff3
[    2.344381] mmc2: host does not support reading read-only switch, assuming write-enable
[    2.349716] mmc2: new high speed SDHC card at address e624
[    2.354396] mmcblk1: mmc2:e624 SU04G 3.69 GiB 
[    2.362506]  mmcblk1: p1 p2 p3
[    2.372593] libphy: 48485000.mdio: probed
[    2.376626] davinci_mdio 48485000.mdio: phy[2]: device 48485000.mdio:02, driver unknown
[    2.384668] davinci_mdio 48485000.mdio: phy[3]: device 48485000.mdio:03, driver unknown
[    2.393389] cpsw 48484000.ethernet: Detected MACID = b4:99:4c:0b:e4:e6
[    2.400896] cpsw 48484000.ethernet: cpsw: Detected MACID = b4:99:4c:0b:e4:e7
[    2.408583] hctosys: unable to open rtc device (rtc0)
[    2.413661] sr_init: No PMIC hook to init smartreflex
[    2.418903] sr_init: platform driver register failed for SR
[    2.441783] net eth0: initializing cpsw version 1.15 (0)
[    2.528312] net eth0: phy found : id is : 0x20005c7a
[    6.531286] cpsw 48484000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[    6.554382] Sending DHCP requests ., OK
[    6.624439] IP-Config: Got DHCP answer from 192.168.0.1, my address is 192.168.0.192
[    6.632426] IP-Config: Complete:
[    6.635674]      device=eth0, hwaddr=b4:99:4c:0b:e4:e6, ipaddr=192.168.0.192, mask=255.255.255.0, gw=192.168.0.1
[    6.645895]      host=192.168.0.192, domain=ti.com, nis-domain=(none)
[    6.652364]      bootserver=192.168.0.1, rootserver=192.168.0.1, rootpath=
[    6.659095]      nameserver0=192.0.2.2, nameserver1=192.0.2.3
[    6.665282] ldousb: disabling
[    6.668549] vmmcwl_fixed: disabling
[    6.672054] aic_dvdd: disabling
[    6.675417] ALSA device list:
[    6.678397]   No soundcards found.
[    6.687614] VFS: Mounted root (nfs filesystem) on device 0:15.
[    6.693779] devtmpfs: mounted
[    6.697044] Freeing unused kernel memory: 372K (c0859000 - c08b6000)

INIT: version 2.88 booting

Starting udev
[    7.129889] udevd[175]: starting version 182
[    7.329630] omap-rproc 58820000.ipu: assigned reserved memory node ipu1_cma@9d000000
[    7.349436]  remoteproc0: 58820000.ipu is available
[    7.358961]  remoteproc0: Note: remoteproc is still under development and considered experimental.
[    7.431205]  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.452181]  remoteproc0: Direct firmware load for dra7-ipu1-fw.xem4 failed with error -2
[    7.456683] omap-rproc 55020000.ipu: assigned reserved memory node ipu2_cma@95800000
[    7.471645]  remoteproc1: 55020000.ipu is available
[    7.471649]  remoteproc1: Note: remoteproc is still under development and considered experimental.
[    7.471653]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.480262] omap-rproc 40800000.dsp: assigned reserved memory node dsp1_cma@99000000
[    7.510612]  remoteproc2: 40800000.dsp is available
[    7.510618]  remoteproc2: Note: remoteproc is still under development and considered experimental.
[    7.510622]  remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.514543] omap-rproc 41000000.dsp: assigned reserved memory node dsp2_cma@9f000000
[    7.523301]  remoteproc3: 41000000.dsp is available
[    7.523306]  remoteproc3: Note: remoteproc is still under development and considered experimental.
[    7.523309]  remoteproc3: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.614060]  remoteproc0: Falling back to user helper
[    7.672048] aic_dvdd: supplied by evm_3v3_sw
[    7.736112] omap_rng 48090000.rng: OMAP Random Number Generator ver. 20
[    8.067185] media: Linux media interface: v0.10
[    8.216475] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc as rtc0
[    8.217206] Linux video capture interface: v2.00
[    8.276707] random: nonblocking pool is initialized
[    8.394957] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    8.420281] platform 48880000.omap_dwc3_1: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    8.423788] ov1063x 1-0037: Failed writing register 0x0103!
[    8.423807] ov1063x: probe of 1-0037 failed with error -121
[    8.488870]  remoteproc0: failed to load dra7-ipu1-fw.xem4
[    8.729862] platform 488c0000.omap_dwc3_2: Driver omap-dwc3 requests probe deferral
[    8.733069] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    8.733072] e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
[    8.733178] e1000e 0000:01:00.0: enabling device (0140 -> 0142)
[    8.733435] e1000e 0000:01:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    8.750383] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[    8.750685] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    8.750692] platform 48880000.omap_dwc3_1: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    8.779935] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[    8.780067] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    8.780073] platform 48880000.omap_dwc3_1: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    8.951061] CAN device driver interface
[    8.963296] e1000e 0000:01:00.0 eth2: registered PHC clock
[    8.963304] e1000e 0000:01:00.0 eth2: (PCI Express:2.5GT/s:Width x1) 68:05:ca:36:2b:25
[    8.963311] e1000e 0000:01:00.0 eth2: Intel(R) PRO/1000 Network Connection
[    8.966445] e1000e 0000:01:00.0 eth2: MAC: 3, PHY: 8, PBA No: E46981-008
[    9.024825] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[    9.027031] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    9.027039] platform 48880000.omap_dwc3_1: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    9.287323]  remoteproc2: Direct firmware load for dra7-dsp1-fw.xe66 failed with error -2
[    9.287327]  remoteproc2: Falling back to user helper
[    9.308265] omap-dwc3 48880000.omap_dwc3_1: **** dwc3_omap_probe done
[    9.341969] platform 488c0000.omap_dwc3_2: deferring probe: ==== Driver omap-dwc3 requests probe deferral
[    9.357153] vpe 489d0000.vpe: loading firmware vpdma-1b8.bin
[    9.363840]  remoteproc1: registered virtio0 (type 7)
[    9.390936] omap-dwc3 488c0000.omap_dwc3_2: **** dwc3_omap_probe done
[    9.411821] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    9.487056] input: gpio_keys as /devices/platform/gpio_keys/input/input0
[    9.530380] asoc-simple-card sound@0: tlv320aic3x-hifi <-> 48468000.mcasp mapping ok
[    9.572735] c_can_platform 4ae3c000.can: c_can_platform device registered (regs=fce3c000, irq=349)
[    9.585025] vip 48970000.vip: loading firmware vpdma-1b8.bin
[    9.592896] ahci 4a140000.sata: SSS flag set, parallel bus scan disabled
[    9.599650] ahci 4a140000.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[    9.608289] ahci 4a140000.sata: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part ccc apst 
[    9.703388] scsi host0: ahci
[    9.763672] omap-hdmi-audio omap-hdmi-audio.0.auto: snd-soc-dummy-dai <-> 58040000.encoder mapping ok
[    9.803153] ata1: SATA max UDMA/133 mmio [mem 0x4a140000-0x4a1410ff] port 0x100 irq 336
[   10.164442] ata1: SATA link down (SStatus 0 SControl 300)
[   10.642315]  remoteproc2: failed to load dra7-dsp1-fw.xe66
[   10.659698]  remoteproc3: Direct firmware load for dra7-dsp2-fw.xe66 failed with error -2
[   10.671669]  remoteproc3: Falling back to user helper
[   10.811525]  remoteproc1: powering up 55020000.ipu
[   10.820600] m25p80 spi32766.0: s25fl256s1 (32768 Kbytes)
[   10.820686] 10 ofpart partitions found on MTD device spi32766.0
[   10.820693] Creating 10 MTD partitions on "spi32766.0":
[   10.820702] 0x000000000000-0x000000010000 : "QSPI.SPL"
[   10.886395] 0x000000010000-0x000000020000 : "QSPI.SPL.backup1"
[   10.895608]  remoteproc3: failed to load dra7-dsp2-fw.xe66
[   10.909877] 0x000000020000-0x000000030000 : "QSPI.SPL.backup2"
[   10.912583] 0x000000030000-0x000000040000 : "QSPI.SPL.backup3"
[   10.913546] 0x000000040000-0x000000140000 : "QSPI.u-boot"
[   10.914433] vip 48970000.vip: VPDMA firmware loaded
[   10.914670] vpe 489d0000.vpe: Device registered as /dev/video0
[   10.938439] 0x000000140000-0x0000001c0000 : "QSPI.u-boot-spl-os"
[   10.962444] 0x0000001c0000-0x0000001d0000 : "QSPI.u-boot-env"
[   11.011549] 0x0000001d0000-0x0000001e0000 : "QSPI.u-boot-env.backup1"
[   11.071277] 0x0000001e0000-0x0000009e0000 : "QSPI.kernel"
[   11.080616] 0x0000009e0000-0x000002000000 : "QSPI.file-system"
[   11.415621] EXT4-fs (mmcblk0p3): mounted filesystem without journal. Opts: (null)
[   11.439508] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   11.476702]  remoteproc1: Booting fw image dra7-ipu2-fw.xem4, size 3480916
[   11.491518] EXT4-fs (mmcblk1p3): mounted filesystem without journal. Opts: (null)
[   11.495115] EXT4-fs (mmcblk1p2): warning: maximal mount count reached, running e2fsck is recommended
[   11.505950] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)
[   11.536011] FAT-fs (mmcblk0p2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   11.641063] FAT-fs (mmcblk1p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   11.690531] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
[   11.894821] dwc3 48890000.usb: **** dwc3_probe done
[   11.972740]  remoteproc1: remote processor 55020000.ipu is now up
[   11.999719] virtio_rpmsg_bus virtio0: rpmsg host is online
[   12.003008] virtio_rpmsg_bus virtio0: creating channel rpmsg-rpc addr 0x3b
[   12.085055] rpmsg_rpc rpmsg0: probing service rpmsg-dce with src 1024 dst 59
[   12.092778] rpmsg_rpc rpmsg0: published functions = 8
[   12.387531] dwc3 488d0000.usb: **** dwc3_probe done
[   12.555405] usbcore: registered new interface driver usbfs
[   12.561001] usbcore: registered new interface driver hub
[   12.566496] usbcore: registered new device driver usb
[   12.619632] dwc3 48890000.usb: otg: primary host xhci-hcd.1.auto registered
[   12.626635] dwc3 48890000.usb: otg: shared host xhci-hcd.1.auto registered
[   12.633543] dwc3 48890000.usb: otg: can't start till gadget registers
[   12.640118] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[   12.645652] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 1
[   12.653905] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[   12.662779] xhci-hcd xhci-hcd.2.auto: irq 463, io mem 0x488d0000
[   12.668985] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[   12.681600] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   12.688857] usb usb1: Product: xHCI Host Controller
[   12.693757] usb usb1: Manufacturer: Linux 4.1.10-rt10-02639-gd63d0be-dirty xhci-hcd
[   12.701448] usb usb1: SerialNumber: xhci-hcd.2.auto
[   12.707274] hub 1-0:1.0: USB hub found
[   12.711077] hub 1-0:1.0: 1 port detected
[   12.715501] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[   12.721021] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 2
[   12.728804] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[   12.737061] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[   12.743880] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   12.751136] usb usb2: Product: xHCI Host Controller
[   12.756039] usb usb2: Manufacturer: Linux 4.1.10-rt10-02639-gd63d0be-dirty xhci-hcd
[   12.763727] usb usb2: SerialNumber: xhci-hcd.2.auto
[   12.769500] hub 2-0:1.0: USB hub found
[   12.773298] hub 2-0:1.0: 1 port detected
bootlogd: cannot allocate pseudo tty: No such file or directory
Starting random number generator daemon.
[   13.034435] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[   13.176262] usb 1-1: New USB device found, idVendor=154b, idProduct=007a
[   13.183002] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   13.190859] usb 1-1: Product: USB 2.0 FD
[   13.194810] usb 1-1: Manufacturer: PNY Technologies
[   13.199717] usb 1-1: SerialNumber: AEC12H25YE11003156
[   13.209498] usb 1-1: ep 0x81 - rounding interval to 128 microframes, ep desc says 255 microframes
[   13.218598] usb 1-1: ep 0x2 - rounding interval to 128 microframes, ep desc says 255 microframes
[   13.280307] usb-storage 1-1:1.0: USB Mass Storage device detected
[   13.287194] scsi host1: usb-storage 1-1:1.0
[   13.293029] usbcore: registered new interface driver usb-storage

Re: Alternative approach to solve the deferred probe

[Grygorii Strashko]

Hi Russell,

On 10/21/2015 09:28 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
>> But I worry a bit (and that my main point) about these few additional
>> rounds of deferred device probing which I have right now and which allows
>> some of drivers to finish, finally, their probes successfully.
>> With proposed change I'll get more messages in boot log, but some of
>> them will belong to drivers which have been probed successfully and so,
>> they will be not really useful.
> 
> Then you haven't properly understood my proposal.
> 
> I want to get rid of all the "X deferred its probing" messages up until
> the point that we set the "please report deferred probes" flag.
> 
> That _should_ mean that all the deferred probing that goes on becomes
> _totally_ silent and becomes hidden (unless you really want to see it,
> in which case we can make a debug option which turns it on) up until
> we're at the point where we want to enter userspace.
> 
> At that point, we then report into the kernel log which devices are
> still deferring and, via appropriately placed dev_warn_deferred(),
> the reasons why the devices are being deferred.
> 
> So, gone will be all the messages earlier in the log about device X
> not having a GPIO/clock/whatever because the device providing the
> GPIO/clock/whatever hasn't been probed.
> 
> If everything is satisfied by the time we run this last round (again,
> I'm not using a three line sentence to describe exactly what I mean,
> I'm sure you know by now... oops, I just did) then the kernel will
> report nothing about any deferrals.  That's _got_ to be an improvement.

Sorry Master, but you really don't need to spend so much time typing the
same things three times  - I understand what are you trying to do :(

I did my comments with assumption that it's not officially prohibited/deprecated
to register drivers (and execute probes) from late_initcall() layer
(just recommended) and there are still bunch of drivers which are doing this.
Now I see that it's not a recommendation any more, and deferred_probe_initcall()
might be a good place to activate driver_deferred_probe_report if goal is to
identify and fix such drivers.

Sorry for your time.

> 
>>
>> As result, I think, the most important thing is to identify (or create)
>> some point during kernel boot when it will be possible to say that all
>> built-in drivers (at least) finish their probes 100% (done or defer).
>>
>> Might be do_initcalls() can be updated (smth like this):
>> static void __init do_initcalls(void)
>> {
>> 	int level;
>>
>> 	for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
>> 		do_initcall_level(level);
>>
>> +	wait_for_device_probe();
>> +	/* Now one final round, reporting any devices that remain deferred */
>> +	driver_deferred_probe_report = true;
>> +	driver_deferred_probe_trigger();
>> +	wait_for_device_probe();
>> }
>>
>> Also, in my opinion, it will be useful if this debugging feature will be
>> optional.
> 
> I wonder why you want it optional... so I'm going to guess and cover
> both cases I can think of below to head off another round of reply on
> this point (sorry if this sucks eggs.)
> 
> I don't see it as being optional, because it's going to be cheap to run
> in the case of a system which has very few or no errors - which is what
> you should have for production systems, right?
> 

Also, I've spend some time today testing your proposal - hope you'll find results
useful.

I've applied truncated version of your patch (diff below) on TI's 4.1 kernel and
run few tests (log is below) on dra7-evm/am43xx-gpevm - K4.1 is not far away from LKML,
so I assume this test is valid. Overall boot process consists from two stages:
kernel boot and modules loading. 

My Changes:
 - only really_probe() modified to show deferred device/drivers 

From the log I can see additional messages in log when modules are loading,
because driver_deferred_probe_report is still true - dwc3 probes were deferred,
but then finally succeeded.

So, as you've mentioned, it seems a good thing to deactivate driver_deferred_probe_report and
provide user with ability to turn it on again (and probably re-trigger deferred
device probing).

I've found no issues during Kernel boot (built-in) time, new messages are displayed only
if probe is failed for some drivers:
[    3.219700] =================== deferred_probe_initcalll
[    3.226820] platform omapdrm.0: Driver omapdrm requests probe deferral
[    3.233378] platform omapdrm.0: deferring probe: == Driver omapdrm requests probe deferral
[    3.242084] dra7evm-tpd12s015 encoder@1: failed to parse CT CP HPD gpio
[    3.248737] platform encoder@1: Driver dra7evm-tpd12s015 requests probe deferral
[    3.256168] platform encoder@1: deferring probe: == Driver dra7evm-tpd12s015 requests probe deferral
[    3.265763] connector-hdmi connector@1: failed to find video source
[    3.272067] platform connector@1: Driver connector-hdmi requests probe deferral
[    3.279410] platform connector@1: deferring probe: == Driver connector-hdmi requests probe deferral 
^^ above drivers will be deferred forever

Thanks.
-- 
regards,
-grygorii
S/ILKP

*************** [TEST CODE] ***********
---
 drivers/base/dd.c | 33 ++++++++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index e7d2545..d61fa47 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -129,6 +129,27 @@ void driver_deferred_probe_del(struct device *dev)
 	mutex_unlock(&deferred_probe_mutex);
 }
 
+static bool driver_deferred_probe_report;
+
+/**
+ * dev_warn_deferred() - report why a probe has been deferred
+ */
+void dev_warn_deferred(struct device *dev, const char *fmt, ...)
+{
+	if (driver_deferred_probe_report) {
+		struct va_format vaf;
+		va_list ap;
+
+		va_start(ap, fmt);
+		vaf.fmt = fmt;
+		vaf.va = &ap;
+
+		dev_err(dev, "deferring probe: %pV", &vaf);
+		va_end(ap);
+	}
+}
+EXPORT_SYMBOL_GPL(dev_warn_deferred);
+
 static bool driver_deferred_probe_enable = false;
 /**
  * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
@@ -188,6 +209,15 @@ static int deferred_probe_initcall(void)
 	driver_deferred_probe_trigger();
 	/* Sort as many dependencies as possible before exiting initcalls */
 	flush_workqueue(deferred_wq);
+
+	pr_err("=================== deferred_probe_initcalll\n");
+
+	/* Now one final round, reporting any devices that remain deferred */
+	driver_deferred_probe_report = true;
+	driver_deferred_probe_trigger();
+	/* Sort as many dependencies as possible before exiting initcalls */
+	flush_workqueue(deferred_wq);
+
 	return 0;
 }
 late_initcall(deferred_probe_initcall);
@@ -342,7 +372,8 @@ probe_failed:
 	switch (ret) {
 	case -EPROBE_DEFER:
 		/* Driver requested deferred probing */
-		dev_dbg(dev, "Driver %s requests probe deferral\n", drv->name);
+		dev_err(dev, "Driver %s requests probe deferral\n", drv->name);
+		dev_warn_deferred(dev, "== Driver %s requests probe deferral\n", drv->name);
 		driver_deferred_probe_add(dev);
 		/* Did a trigger occur while probing? Need to re-trigger if yes */
 		if (local_trigger_count != atomic_read(&deferred_trigger_count))
-- 
2.6.2


*************** [BOOT LOG] ***********
Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.1.10-rt10-02639-gd63d0be-dirty (lcpdbld@dflsdit-build06.dal.design.ti.com) (gcc version 4.9.3 20150413 (prerelease) (Linaro GCC 4.9-2015.05) ) #1 SMP PREEMPT RT Thu Oct 22 05:11:58 CDT 2015
[    0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr\x10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] Machine model: TI DRA742
[    0.000000] Reserved memory: created CMA memory pool at 0x95800000, size 56 MiB
[    0.000000] Reserved memory: initialized node ipu2_cma@95800000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x99000000, size 64 MiB
[    0.000000] Reserved memory: initialized node dsp1_cma@99000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x9d000000, size 32 MiB
[    0.000000] Reserved memory: initialized node ipu1_cma@9d000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x9f000000, size 8 MiB
[    0.000000] Reserved memory: initialized node dsp2_cma@9f000000, compatible id shared-dma-pool
[    0.000000] cma: Reserved 24 MiB at 0xde000000
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] DRA752 ES1.1
[    0.000000] PERCPU: Embedded 12 pages/cpu @ee9af000 s17792 r8192 d23168 u49152
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 390994
[    0.000000] Kernel command line: console=ttyO0,115200n8 earlyprintk rootwait  ip=:::::eth0:dhcp  root=/dev/nfs rw nfsroot\x192.168.0.1:/home/tigtfarm07/NFS_exports/dra7xx-evm1/autofs/1d8e30535854dc371534f96e3c6d5488,nolock 
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 1356664K/1570816K available (6271K kernel code, 508K rwdata, 2240K rodata, 372K init, 266K bss, 25736K reserved, 188416K cma-reserved, 768000K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0858064   (8513 kB)
[    0.000000]       .init : 0xc0859000 - 0xc08b6000   ( 372 kB)
[    0.000000]       .data : 0xc08b6000 - 0xc09352c0   ( 509 kB)
[    0.000000]        .bss : 0xc0938000 - 0xc097ab78   ( 267 kB)
[    0.000000] SLUB: HWalignd, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] 	Additional per-CPU info printed with stalls.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] 	Offload RCU callbacks from all CPUs
[    0.000000] 	Offload RCU callbacks from CPUs: 0-1.
[    0.000000] OMAP clockevent source: timer1 at 32768 Hz
[    0.000000] clocksource 32k_counter: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 65535999984741ns
[    0.000000] OMAP clocksource: 32k_counter at 32768 Hz
[    0.000427] Architected cp15 timer(s) running at 6.14MHz (virt).
[    0.000457] clocksource arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x16af5adb9, max_idle_ns: 440795202250 ns
[    0.000463] sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 4398046511023ns
[    0.000470] Switching to timer-based delay loop, resolution 162ns
[    0.001360] Console: colour dummy device 80x30
[    0.001486] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
[    0.001488] This ensures that you still see kernel messages. Please
[    0.001489] update your kernel commandline.
[    0.001502] Calibrating delay loop (skipped), value calculated using timer frequency.. 12.29 BogoMIPS (lpja475)
[    0.001506] pid_max: default: 32768 minimum: 301
[    0.001583] Security Framework initialized
[    0.001620] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.001626] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.002189] Initializing cgroup subsys blkio
[    0.002197] Initializing cgroup subsys memory
[    0.002221] Initializing cgroup subsys devices
[    0.002228] Initializing cgroup subsys freezer
[    0.002236] Initializing cgroup subsys perf_event
[    0.002278] CPU: Testing write buffer coherency: ok
[    0.002517] /cpus/cpu@0 missing clock-frequency property
[    0.002598] /cpus/cpu@1 missing clock-frequency property
[    0.002609] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.002653] Setting up static identity map for 0x80008280 - 0x800082f0
[    0.120957] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.121040] Brought up 2 CPUs
[    0.121054] SMP: Total of 2 processors activated (24.59 BogoMIPS).
[    0.121061] CPU: All CPU(s) started in SVC mode.
[    0.121513] devtmpfs: initialized
[    0.149180] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
[    0.149968] omap_hwmod: l3_main_2 using broken dt data from ocp
[    0.164029] omap_hwmod: tptc0 using broken dt data from edma-controller
[    0.164509] omap_hwmod: tptc1 using broken dt data from edma-controller
[    0.338569] clocksource jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.342242] pinctrl core: initialized pinctrl subsystem
[    0.343204] NET: Registered protocol family 16
[    0.345772] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.354459] OMAP GPIO hardware version 0.1
[    0.362174] irq: no irq domain found for /ocp/l4@4a000000/scm@2000/pinmux@1400 !
[    0.388931] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[    0.388942] hw-breakpoint: maximum watchpoint size is 8 bytes.
[    0.391765] omap4_sram_init:Unable to allocate sram needed to handle errata I688
[    0.391775] omap4_sram_init:Unable to get sram pool needed to handle errata I688
[    0.392434] OMAP DMA hardware revision 0.0
[    0.409403] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver
[    0.412466] omap-dma-engine 4a056000.dma-controller: OMAP DMA engine driver
[    0.413035] platform fixedregulator-sd: Driver reg-fixed-voltage requests probe deferral
[    0.418357] omap-iommu 40d01000.mmu: 40d01000.mmu registered
[    0.418619] omap-iommu 40d02000.mmu: 40d02000.mmu registered
[    0.418864] omap-iommu 58882000.mmu: 58882000.mmu registered
[    0.419116] omap-iommu 55082000.mmu: 55082000.mmu registered
[    0.419488] omap-iommu 41501000.mmu: 41501000.mmu registered
[    0.419750] omap-iommu 41502000.mmu: 41502000.mmu registered
[    0.420001] vgaarb: loaded
[    0.420424] SCSI subsystem initialized
[    0.421911] palmas 0-0058: IRQ missing: skipping irq request
[    0.441468] palmas 0-0058: Muxing GPIO 2e, PWM 0, LED 0
[    0.513681] pcf857x 0-0020: probed
[    0.514304] pcf857x 0-0021: probed
[    0.514450] omap_i2c 48070000.i2c: bus 0 rev0.12 at 400 kHz
[    0.531230] GPIO line 465 (vin6_sel_s0) hogged as output/low
[    0.531421] pcf857x 1-0026: probed
[    0.531580] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
[    0.532021] omap_i2c 48060000.i2c: bus 2 rev0.12 at 400 kHz
[    0.532308] pps_core: LinuxPPS API ver. 1 registered
[    0.532317] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.532346] PTP clock support registered
[    0.533009] omap-mailbox 48840000.mailbox: omap mailbox rev 0x400
[    0.533319] omap-mailbox 48842000.mailbox: omap mailbox rev 0x400
[    0.533623] Advanced Linux Sound Architecture Driver Initialized.
[    0.534366] Switched to clocksource arch_sys_counter
[    0.544551] NET: Registered protocol family 2
[    0.545253] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    0.545334] TCP bind hash table entries: 8192 (order: 5, 229376 bytes)
[    0.545623] TCP: Hash tables configured (established 8192 bind 8192)
[    0.545685] UDP hash table entries: 512 (order: 3, 32768 bytes)
[    0.545741] UDP-Lite hash table entries: 512 (order: 3, 32768 bytes)
[    0.545949] NET: Registered protocol family 1
[    0.546240] RPC: Registered named UNIX socket transport module.
[    0.546249] RPC: Registered udp transport module.
[    0.546256] RPC: Registered tcp transport module.
[    0.546263] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.547419] CPU PMU: Failed to parse /pmu/interrupt-affinity[0]
[    0.547454] hw perfevents: enabled with armv7_cortex_a15 PMU driver, 7 counters available
[    0.549458] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.549541] audit: initializing netlink subsys (disabled)
[    0.549576] audit: type 00 audit(0.530:1): initialized
[    0.556198] VFS: Disk quotas dquot_6.6.0
[    0.556369] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.558508] NFS: Registering the id_resolver key type
[    0.558542] Key type id_resolver registered
[    0.558550] Key type id_legacy registered
[    0.558610] jffs2: version 2.2. (NAND) (SUMMARY)   2001-2006 Red Hat, Inc.
[    0.560591] NET: Registered protocol family 38
[    0.560698] bounce: pool size: 64 pages
[    0.560713] io scheduler noop registered
[    0.560727] io scheduler deadline registered
[    0.560879] io scheduler cfq registered (default)
[    0.564728] pinctrl-single 4a003400.pinmux: 281 pins at pa fc003400 size 1124
[    0.574576] dra7-pcie 51000000.pcie: PCI host bridge to bus 0000:00
[    0.574590] pci_bus 0000:00: root bus resource [io  0x1000-0xffff]
[    0.574600] pci_bus 0000:00: root bus resource [mem 0x20013000-0x2fffffff]
[    0.574612] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.574765] pci 0000:00:00.0: IOMMU is currently not supported for PCI
[    0.575026] PCI: bus0: Fast back to back transfers disabled
[    0.575470] pci 0000:01:00.0: IOMMU is currently not supported for PCI
[    0.575814] PCI: bus1: Fast back to back transfers disabled
[    0.575950] pci 0000:00:00.0: BAR 0: assigned [mem 0x20100000-0x201fffff]
[    0.575966] pci 0000:00:00.0: BAR 8: assigned [mem 0x20200000-0x202fffff]
[    0.575978] pci 0000:00:00.0: BAR 9: assigned [mem 0x20300000-0x203fffff pref]
[    0.575989] pci 0000:00:00.0: BAR 1: assigned [mem 0x20020000-0x2002ffff]
[    0.576002] pci 0000:00:00.0: BAR 7: assigned [io  0x1000-0x1fff]
[    0.576017] pci 0000:01:00.0: BAR 1: assigned [mem 0x20200000-0x2027ffff]
[    0.576037] pci 0000:01:00.0: BAR 6: assigned [mem 0x20300000-0x2033ffff pref]
[    0.576048] pci 0000:01:00.0: BAR 0: assigned [mem 0x20280000-0x2029ffff]
[    0.576067] pci 0000:01:00.0: BAR 3: assigned [mem 0x202a0000-0x202a3fff]
[    0.576086] pci 0000:01:00.0: BAR 2: assigned [io  0x1000-0x101f]
[    0.576106] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.576116] pci 0000:00:00.0:   bridge window [io  0x1000-0x1fff]
[    0.576128] pci 0000:00:00.0:   bridge window [mem 0x20200000-0x202fffff]
[    0.576138] pci 0000:00:00.0:   bridge window [mem 0x20300000-0x203fffff pref]
[    0.579925] OMAP DSS rev 6.1
[    0.580244] omapdss_dss 58000000.dss: bound 58001000.dispc (ops dispc_component_ops)
[    0.580839] omapdss_dss 58000000.dss: bound 58040000.encoder (ops hdmi5_component_ops)
[    0.581749] platform encoder@1: Driver dra7evm-tpd12s015 requests probe deferral
[    0.582201] connector-hdmi connector@1: failed to find video source
[    0.582219] platform connector@1: Driver connector-hdmi requests probe deferral
[    0.585743] Serial: 8250/16550 driver, 10 ports, IRQ sharing enabled
[    0.588508] 4806a000.serial: ttyS0 at MMIO 0x4806a000 (irq = 299, base_baud = 3000000) is a 8250
[    1.662547] console [ttyS0] enabled
[    1.666661] 4806c000.serial: ttyS1 at MMIO 0x4806c000 (irq = 300, base_baud = 3000000) is a 8250
[    1.676287] 48020000.serial: ttyS2 at MMIO 0x48020000 (irq = 301, base_baud = 3000000) is a 8250
[    1.686280] [drm] Initialized drm 1.1.0 20060810
[    1.700726] brd: module loaded
[    1.708417] loop: module loaded
[    1.712651] mtdoops: mtd device (mtddev=name/number) must be supplied
[    1.723546] mousedev: PS/2 mouse device common for all mice
[    1.729154] i2c /dev entries driver
[    1.734581] omap_hsmmc 4809c000.mmc: Got CD GPIO
[    1.739413] omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
[    1.746235] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
[    1.753335] platform 4809c000.mmc: Driver omap_hsmmc requests probe deferral
[    1.760862] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr104 mode
[    1.767334] omap_hsmmc 480b4000.mmc: no pinctrl state for hs200_1_8v mode
[    1.774151] omap_hsmmc 480b4000.mmc: no pinctrl state for ddr50 mode
[    1.780537] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr50 mode
[    1.786920] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr25 mode
[    1.793302] omap_hsmmc 480b4000.mmc: no pinctrl state for sdr12 mode
[    1.800000] evm_3v3_sw: supplied by sysen1
[    1.845119] omap_hsmmc 480d1000.mmc: no pinctrl state for sdr104 mode
[    1.851589] omap_hsmmc 480d1000.mmc: no pinctrl state for hs200_1_8v mode
[    1.858426] omap_hsmmc 480d1000.mmc: no pinctrl state for ddr50 mode
[    1.864810] omap_hsmmc 480d1000.mmc: no pinctrl state for sdr50 mode
[    1.871192] omap_hsmmc 480d1000.mmc: no pinctrl state for ddr_1_8v mode
[    1.888212] mmc0: MAN_BKOPS_EN bit is not set
[    1.896106] mmc0: new DDR MMC card at address 0001
[    1.901266] mmcblk0: mmc0:0001 MMC08G 7.25 GiB 
[    1.905933] mmcblk0boot0: mmc0:0001 MMC08G partition 1 8.00 MiB
[    1.911994] mmcblk0boot1: mmc0:0001 MMC08G partition 2 8.00 MiB
[    1.918716]  mmcblk0: p1 p2 p3
[    1.995125] omap-aes 4b500000.aes: OMAP AES hw accel rev: 3.3
[    2.001694] omap-aes 4b700000.aes: OMAP AES hw accel rev: 3.3
[    2.009016] omap-des 480a5000.des: OMAP DES hw accel rev: 2.2
[    2.015924] omap-sham 4b101000.sham: hw accel on OMAP rev 4.3
[    2.026077] davinci-mcasp 48468000.mcasp: ERRATA i868 workaround is enabled
[    2.035132] davinci-mcasp 4847c000.mcasp: ERRATA i868 workaround is enabled
[    2.042544] Initializing XFRM netlink socket
[    2.046882] NET: Registered protocol family 17
[    2.051375] NET: Registered protocol family 15
[    2.055925] Key type dns_resolver registered
[    2.060338] omap_voltage_late_init: Voltage driver support not added
[    2.066734] sr_dev_init: Unable to get voltage domain pointer for VDD core
[    2.073638] sr_dev_init: Unable to get voltage domain pointer for VDD mpu
[    2.080738] Power Management for TI OMAP4+ devices.
[    2.085863] ThumbEE CPU extension supported.
[    2.090164] Registering SWP/SWPB emulation handler
[    2.094984] SmartReflex Class3 initialized
[    2.100743] dmm 4e000000.dmm: workaround for errata i878 in use
[    2.108418] dmm 4e000000.dmm: initialized all PAT entries
[    2.114210] platform omapdrm.0: Driver omapdrm requests probe deferral
[    2.123162] omap_hsmmc 4809c000.mmc: Got CD GPIO
[    2.128009] omap_hsmmc 4809c000.mmc: no pinctrl state for hs200_1_8v mode
[    2.134830] omap_hsmmc 4809c000.mmc: no pinctrl state for ddr_1_8v mode
[    2.196401] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    2.203044] [drm] No driver support for vblank timestamp query.
[    2.209023] omapdrm omapdrm.0: No connectors reported connected with modes
[    2.215933] [drm] Cannot find any crtc or sizes - going 1024x768
[    2.227640] [drm] Enabling DMM ywrap scrolling
[    2.239535] Console: switching to colour frame buffer device 128x48
[    2.251305] omapdrm omapdrm.0: fb0: omapdrm frame buffer device
[    2.257253] omapdrm omapdrm.0: registered panic notifier
[    2.274429] [drm] Initialized omapdrm 1.0.0 20110917 on minor 0
[    2.280400] =================== deferred_probe_initcalll
[    2.334387] davinci_mdio 48485000.mdio: davinci mdio revision 1.6
[    2.340513] davinci_mdio 48485000.mdio: detected phy mask fffffff3
[    2.344381] mmc2: host does not support reading read-only switch, assuming write-enable
[    2.349716] mmc2: new high speed SDHC card at address e624
[    2.354396] mmcblk1: mmc2:e624 SU04G 3.69 GiB 
[    2.362506]  mmcblk1: p1 p2 p3
[    2.372593] libphy: 48485000.mdio: probed
[    2.376626] davinci_mdio 48485000.mdio: phy[2]: device 48485000.mdio:02, driver unknown
[    2.384668] davinci_mdio 48485000.mdio: phy[3]: device 48485000.mdio:03, driver unknown
[    2.393389] cpsw 48484000.ethernet: Detected MACID = b4:99:4c:0b:e4:e6
[    2.400896] cpsw 48484000.ethernet: cpsw: Detected MACID = b4:99:4c:0b:e4:e7
[    2.408583] hctosys: unable to open rtc device (rtc0)
[    2.413661] sr_init: No PMIC hook to init smartreflex
[    2.418903] sr_init: platform driver register failed for SR
[    2.441783] net eth0: initializing cpsw version 1.15 (0)
[    2.528312] net eth0: phy found : id is : 0x20005c7a
[    6.531286] cpsw 48484000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[    6.554382] Sending DHCP requests ., OK
[    6.624439] IP-Config: Got DHCP answer from 192.168.0.1, my address is 192.168.0.192
[    6.632426] IP-Config: Complete:
[    6.635674]      device=eth0, hwaddr´:99:4c:0b:e4:e6, ipaddr\x192.168.0.192, mask%5.255.255.0, gw\x192.168.0.1
[    6.645895]      host\x192.168.0.192, domain=ti.com, nis-domain=(none)
[    6.652364]      bootserver\x192.168.0.1, rootserver\x192.168.0.1, rootpath[    6.659095]      nameserver0\x192.0.2.2, nameserver1\x192.0.2.3
[    6.665282] ldousb: disabling
[    6.668549] vmmcwl_fixed: disabling
[    6.672054] aic_dvdd: disabling
[    6.675417] ALSA device list:
[    6.678397]   No soundcards found.
[    6.687614] VFS: Mounted root (nfs filesystem) on device 0:15.
[    6.693779] devtmpfs: mounted
[    6.697044] Freeing unused kernel memory: 372K (c0859000 - c08b6000)

INIT: version 2.88 booting

Starting udev
[    7.129889] udevd[175]: starting version 182
[    7.329630] omap-rproc 58820000.ipu: assigned reserved memory node ipu1_cma@9d000000
[    7.349436]  remoteproc0: 58820000.ipu is available
[    7.358961]  remoteproc0: Note: remoteproc is still under development and considered experimental.
[    7.431205]  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.452181]  remoteproc0: Direct firmware load for dra7-ipu1-fw.xem4 failed with error -2
[    7.456683] omap-rproc 55020000.ipu: assigned reserved memory node ipu2_cma@95800000
[    7.471645]  remoteproc1: 55020000.ipu is available
[    7.471649]  remoteproc1: Note: remoteproc is still under development and considered experimental.
[    7.471653]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.480262] omap-rproc 40800000.dsp: assigned reserved memory node dsp1_cma@99000000
[    7.510612]  remoteproc2: 40800000.dsp is available
[    7.510618]  remoteproc2: Note: remoteproc is still under development and considered experimental.
[    7.510622]  remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.514543] omap-rproc 41000000.dsp: assigned reserved memory node dsp2_cma@9f000000
[    7.523301]  remoteproc3: 41000000.dsp is available
[    7.523306]  remoteproc3: Note: remoteproc is still under development and considered experimental.
[    7.523309]  remoteproc3: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
[    7.614060]  remoteproc0: Falling back to user helper
[    7.672048] aic_dvdd: supplied by evm_3v3_sw
[    7.736112] omap_rng 48090000.rng: OMAP Random Number Generator ver. 20
[    8.067185] media: Linux media interface: v0.10
[    8.216475] omap_rtc 48838000.rtc: rtc core: registered 48838000.rtc as rtc0
[    8.217206] Linux video capture interface: v2.00
[    8.276707] random: nonblocking pool is initialized
[    8.394957] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    8.420281] platform 48880000.omap_dwc3_1: deferring probe: == Driver omap-dwc3 requests probe deferral
[    8.423788] ov1063x 1-0037: Failed writing register 0x0103!
[    8.423807] ov1063x: probe of 1-0037 failed with error -121
[    8.488870]  remoteproc0: failed to load dra7-ipu1-fw.xem4
[    8.729862] platform 488c0000.omap_dwc3_2: Driver omap-dwc3 requests probe deferral
[    8.733069] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    8.733072] e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
[    8.733178] e1000e 0000:01:00.0: enabling device (0140 -> 0142)
[    8.733435] e1000e 0000:01:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    8.750383] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[    8.750685] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    8.750692] platform 48880000.omap_dwc3_1: deferring probe: == Driver omap-dwc3 requests probe deferral
[    8.779935] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[    8.780067] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    8.780073] platform 48880000.omap_dwc3_1: deferring probe: == Driver omap-dwc3 requests probe deferral
[    8.951061] CAN device driver interface
[    8.963296] e1000e 0000:01:00.0 eth2: registered PHC clock
[    8.963304] e1000e 0000:01:00.0 eth2: (PCI Express:2.5GT/s:Width x1) 68:05:ca:36:2b:25
[    8.963311] e1000e 0000:01:00.0 eth2: Intel(R) PRO/1000 Network Connection
[    8.966445] e1000e 0000:01:00.0 eth2: MAC: 3, PHY: 8, PBA No: E46981-008
[    9.024825] omap_hwmod: usb_otg_ss1: _wait_target_disable failed
[    9.027031] platform 48880000.omap_dwc3_1: Driver omap-dwc3 requests probe deferral
[    9.027039] platform 48880000.omap_dwc3_1: deferring probe: == Driver omap-dwc3 requests probe deferral
[    9.287323]  remoteproc2: Direct firmware load for dra7-dsp1-fw.xe66 failed with error -2
[    9.287327]  remoteproc2: Falling back to user helper
[    9.308265] omap-dwc3 48880000.omap_dwc3_1: **** dwc3_omap_probe done
[    9.341969] platform 488c0000.omap_dwc3_2: deferring probe: == Driver omap-dwc3 requests probe deferral
[    9.357153] vpe 489d0000.vpe: loading firmware vpdma-1b8.bin
[    9.363840]  remoteproc1: registered virtio0 (type 7)
[    9.390936] omap-dwc3 488c0000.omap_dwc3_2: **** dwc3_omap_probe done
[    9.411821] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    9.487056] input: gpio_keys as /devices/platform/gpio_keys/input/input0
[    9.530380] asoc-simple-card sound@0: tlv320aic3x-hifi <-> 48468000.mcasp mapping ok
[    9.572735] c_can_platform 4ae3c000.can: c_can_platform device registered (regsüe3c000, irq49)
[    9.585025] vip 48970000.vip: loading firmware vpdma-1b8.bin
[    9.592896] ahci 4a140000.sata: SSS flag set, parallel bus scan disabled
[    9.599650] ahci 4a140000.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[    9.608289] ahci 4a140000.sata: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part ccc apst 
[    9.703388] scsi host0: ahci
[    9.763672] omap-hdmi-audio omap-hdmi-audio.0.auto: snd-soc-dummy-dai <-> 58040000.encoder mapping ok
[    9.803153] ata1: SATA max UDMA/133 mmio [mem 0x4a140000-0x4a1410ff] port 0x100 irq 336
[   10.164442] ata1: SATA link down (SStatus 0 SControl 300)
[   10.642315]  remoteproc2: failed to load dra7-dsp1-fw.xe66
[   10.659698]  remoteproc3: Direct firmware load for dra7-dsp2-fw.xe66 failed with error -2
[   10.671669]  remoteproc3: Falling back to user helper
[   10.811525]  remoteproc1: powering up 55020000.ipu
[   10.820600] m25p80 spi32766.0: s25fl256s1 (32768 Kbytes)
[   10.820686] 10 ofpart partitions found on MTD device spi32766.0
[   10.820693] Creating 10 MTD partitions on "spi32766.0":
[   10.820702] 0x000000000000-0x000000010000 : "QSPI.SPL"
[   10.886395] 0x000000010000-0x000000020000 : "QSPI.SPL.backup1"
[   10.895608]  remoteproc3: failed to load dra7-dsp2-fw.xe66
[   10.909877] 0x000000020000-0x000000030000 : "QSPI.SPL.backup2"
[   10.912583] 0x000000030000-0x000000040000 : "QSPI.SPL.backup3"
[   10.913546] 0x000000040000-0x000000140000 : "QSPI.u-boot"
[   10.914433] vip 48970000.vip: VPDMA firmware loaded
[   10.914670] vpe 489d0000.vpe: Device registered as /dev/video0
[   10.938439] 0x000000140000-0x0000001c0000 : "QSPI.u-boot-spl-os"
[   10.962444] 0x0000001c0000-0x0000001d0000 : "QSPI.u-boot-env"
[   11.011549] 0x0000001d0000-0x0000001e0000 : "QSPI.u-boot-env.backup1"
[   11.071277] 0x0000001e0000-0x0000009e0000 : "QSPI.kernel"
[   11.080616] 0x0000009e0000-0x000002000000 : "QSPI.file-system"
[   11.415621] EXT4-fs (mmcblk0p3): mounted filesystem without journal. Opts: (null)
[   11.439508] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   11.476702]  remoteproc1: Booting fw image dra7-ipu2-fw.xem4, size 3480916
[   11.491518] EXT4-fs (mmcblk1p3): mounted filesystem without journal. Opts: (null)
[   11.495115] EXT4-fs (mmcblk1p2): warning: maximal mount count reached, running e2fsck is recommended
[   11.505950] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)
[   11.536011] FAT-fs (mmcblk0p2): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   11.641063] FAT-fs (mmcblk1p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[   11.690531] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
[   11.894821] dwc3 48890000.usb: **** dwc3_probe done
[   11.972740]  remoteproc1: remote processor 55020000.ipu is now up
[   11.999719] virtio_rpmsg_bus virtio0: rpmsg host is online
[   12.003008] virtio_rpmsg_bus virtio0: creating channel rpmsg-rpc addr 0x3b
[   12.085055] rpmsg_rpc rpmsg0: probing service rpmsg-dce with src 1024 dst 59
[   12.092778] rpmsg_rpc rpmsg0: published functions = 8
[   12.387531] dwc3 488d0000.usb: **** dwc3_probe done
[   12.555405] usbcore: registered new interface driver usbfs
[   12.561001] usbcore: registered new interface driver hub
[   12.566496] usbcore: registered new device driver usb
[   12.619632] dwc3 48890000.usb: otg: primary host xhci-hcd.1.auto registered
[   12.626635] dwc3 48890000.usb: otg: shared host xhci-hcd.1.auto registered
[   12.633543] dwc3 48890000.usb: otg: can't start till gadget registers
[   12.640118] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[   12.645652] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 1
[   12.653905] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[   12.662779] xhci-hcd xhci-hcd.2.auto: irq 463, io mem 0x488d0000
[   12.668985] usb usb1: New USB device found, idVendor\x1d6b, idProduct\002
[   12.681600] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   12.688857] usb usb1: Product: xHCI Host Controller
[   12.693757] usb usb1: Manufacturer: Linux 4.1.10-rt10-02639-gd63d0be-dirty xhci-hcd
[   12.701448] usb usb1: SerialNumber: xhci-hcd.2.auto
[   12.707274] hub 1-0:1.0: USB hub found
[   12.711077] hub 1-0:1.0: 1 port detected
[   12.715501] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[   12.721021] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 2
[   12.728804] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[   12.737061] usb usb2: New USB device found, idVendor\x1d6b, idProduct\003
[   12.743880] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   12.751136] usb usb2: Product: xHCI Host Controller
[   12.756039] usb usb2: Manufacturer: Linux 4.1.10-rt10-02639-gd63d0be-dirty xhci-hcd
[   12.763727] usb usb2: SerialNumber: xhci-hcd.2.auto
[   12.769500] hub 2-0:1.0: USB hub found
[   12.773298] hub 2-0:1.0: 1 port detected
bootlogd: cannot allocate pseudo tty: No such file or directory
Starting random number generator daemon.
[   13.034435] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[   13.176262] usb 1-1: New USB device found, idVendor\x154b, idProduct\07a
[   13.183002] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   13.190859] usb 1-1: Product: USB 2.0 FD
[   13.194810] usb 1-1: Manufacturer: PNY Technologies
[   13.199717] usb 1-1: SerialNumber: AEC12H25YE11003156
[   13.209498] usb 1-1: ep 0x81 - rounding interval to 128 microframes, ep desc says 255 microframes
[   13.218598] usb 1-1: ep 0x2 - rounding interval to 128 microframes, ep desc says 255 microframes
[   13.280307] usb-storage 1-1:1.0: USB Mass Storage device detected
[   13.287194] scsi host1: usb-storage 1-1:1.0
[   13.293029] usbcore: registered new interface driver usb-storage

Re: [GIT PULL] On-demand device probing

[Frank Rowand]

On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> <oops, sent too early...>
> 
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>> But that's moot currently because Greg believes that the time spent
>> probing devices at boot time could be reduced enough so that the order
>> in which devices are probed becomes irrelevant. IME that would have to
>> be under 200ms so that the user doesn't notice and that's unicorn-far
>> from any bootlog I have ever seen.
> 
> But as no one has actually produced a bootlog, how do you know that?
> Where exactly is your time being spent?  What driver is causing long
> delays?  Why is the long-delay-drivers not being done in their own
> thread?  And most importantly, why are you ignoring the work that people
> did back in 2008 to solve the issue on other hardware platforms?
> 
>> Given that downstreams are already carrying as many hacks as they
>> could think of to speed total boot up, I think this is effectively
>> telling them to go away.
> 
> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> solve-the-random-issue-i'm-having type patch by putting random calls in
> semi-random subsystems all over the kernel.
> 
> And when I ask for real data, you respond with the fact that you aren't
> trying to speed up boot time here at all, so what am I supposed to think

I also had the understanding that this patch series was about improving
boot time.  But I was kindly corrected that the behavior change was
getting the panel displaying stuff at an earlier point in the boot sequence,
_not_ completing the entire boot faster. 

The claim for the current series, in patch 0 in v7 is:

   With this series I get the kernel to output to the panel in 0.5s,
   instead of 2.8s.

Just to get side-tracked, one other approach at ordering to reduce
deferrals reported a modest boot time reduction for four boards and a
very slight boot time increase for one other board.) The report of boot
times with that approach was in:

  http://article.gmane.org/gmane.linux.drivers.devicetree/133010

from Alexander Holler.

I have not searched further to see if there is more data of boot time
reductions from any of the other attempts to change driver binding
order to move dependencies before use of a resource.  But whether
there is a performance improvement or not, there continues to be
a stream of developers creatively impacting the binding order for
their specific driver(s) or board.  So it seems that maybe there
is an underlying problem, or we don't have adequate documentation
explaining how to avoid a need to order bindings, or the
documentation exists and is not being read.

I have been defaulting to the position that has been asserted by
the device tree maintainters, that probe deferrals work just fine
for at least the majority of cases (and is the message I have been
sharing in my conference presentations about device tree).  But I
suspect that there is at least a small minority of cases that are not
well served by probe deferral.  (Not to be read as an endorsement of
this specific patch series, just a generic observation.)

-Frank

> other than that you don't care enough to do the real work and are trying
> to hack the driver core up instead.
> 
>> Sorry for the rant,
> 
> No apologies needed, it's cathartic at times :)
> 
> thanks,
> 
> greg k-h
> .
> 

Re: [GIT PULL] On-demand device probing

[Frank Rowand]

On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> <oops, sent too early...>
> 
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>> But that's moot currently because Greg believes that the time spent
>> probing devices at boot time could be reduced enough so that the order
>> in which devices are probed becomes irrelevant. IME that would have to
>> be under 200ms so that the user doesn't notice and that's unicorn-far
>> from any bootlog I have ever seen.
> 
> But as no one has actually produced a bootlog, how do you know that?
> Where exactly is your time being spent?  What driver is causing long
> delays?  Why is the long-delay-drivers not being done in their own
> thread?  And most importantly, why are you ignoring the work that people
> did back in 2008 to solve the issue on other hardware platforms?
> 
>> Given that downstreams are already carrying as many hacks as they
>> could think of to speed total boot up, I think this is effectively
>> telling them to go away.
> 
> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> solve-the-random-issue-i'm-having type patch by putting random calls in
> semi-random subsystems all over the kernel.
> 
> And when I ask for real data, you respond with the fact that you aren't
> trying to speed up boot time here at all, so what am I supposed to think

I also had the understanding that this patch series was about improving
boot time.  But I was kindly corrected that the behavior change was
getting the panel displaying stuff at an earlier point in the boot sequence,
_not_ completing the entire boot faster. 

The claim for the current series, in patch 0 in v7 is:

   With this series I get the kernel to output to the panel in 0.5s,
   instead of 2.8s.

Just to get side-tracked, one other approach at ordering to reduce
deferrals reported a modest boot time reduction for four boards and a
very slight boot time increase for one other board.) The report of boot
times with that approach was in:

  http://article.gmane.org/gmane.linux.drivers.devicetree/133010

from Alexander Holler.

I have not searched further to see if there is more data of boot time
reductions from any of the other attempts to change driver binding
order to move dependencies before use of a resource.  But whether
there is a performance improvement or not, there continues to be
a stream of developers creatively impacting the binding order for
their specific driver(s) or board.  So it seems that maybe there
is an underlying problem, or we don't have adequate documentation
explaining how to avoid a need to order bindings, or the
documentation exists and is not being read.

I have been defaulting to the position that has been asserted by
the device tree maintainters, that probe deferrals work just fine
for at least the majority of cases (and is the message I have been
sharing in my conference presentations about device tree).  But I
suspect that there is at least a small minority of cases that are not
well served by probe deferral.  (Not to be read as an endorsement of
this specific patch series, just a generic observation.)

-Frank

> other than that you don't care enough to do the real work and are trying
> to hack the driver core up instead.
> 
>> Sorry for the rant,
> 
> No apologies needed, it's cathartic at times :)
> 
> thanks,
> 
> greg k-h
> .
> 

Re: [GIT PULL] On-demand device probing

[Frank Rowand]

On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> <oops, sent too early...>
> 
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>> But that's moot currently because Greg believes that the time spent
>> probing devices at boot time could be reduced enough so that the order
>> in which devices are probed becomes irrelevant. IME that would have to
>> be under 200ms so that the user doesn't notice and that's unicorn-far
>> from any bootlog I have ever seen.
> 
> But as no one has actually produced a bootlog, how do you know that?
> Where exactly is your time being spent?  What driver is causing long
> delays?  Why is the long-delay-drivers not being done in their own
> thread?  And most importantly, why are you ignoring the work that people
> did back in 2008 to solve the issue on other hardware platforms?
> 
>> Given that downstreams are already carrying as many hacks as they
>> could think of to speed total boot up, I think this is effectively
>> telling them to go away.
> 
> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> solve-the-random-issue-i'm-having type patch by putting random calls in
> semi-random subsystems all over the kernel.
> 
> And when I ask for real data, you respond with the fact that you aren't
> trying to speed up boot time here at all, so what am I supposed to think

I also had the understanding that this patch series was about improving
boot time.  But I was kindly corrected that the behavior change was
getting the panel displaying stuff at an earlier point in the boot sequence,
_not_ completing the entire boot faster. 

The claim for the current series, in patch 0 in v7 is:

   With this series I get the kernel to output to the panel in 0.5s,
   instead of 2.8s.

Just to get side-tracked, one other approach at ordering to reduce
deferrals reported a modest boot time reduction for four boards and a
very slight boot time increase for one other board.) The report of boot
times with that approach was in:

  http://article.gmane.org/gmane.linux.drivers.devicetree/133010

from Alexander Holler.

I have not searched further to see if there is more data of boot time
reductions from any of the other attempts to change driver binding
order to move dependencies before use of a resource.  But whether
there is a performance improvement or not, there continues to be
a stream of developers creatively impacting the binding order for
their specific driver(s) or board.  So it seems that maybe there
is an underlying problem, or we don't have adequate documentation
explaining how to avoid a need to order bindings, or the
documentation exists and is not being read.

I have been defaulting to the position that has been asserted by
the device tree maintainters, that probe deferrals work just fine
for at least the majority of cases (and is the message I have been
sharing in my conference presentations about device tree).  But I
suspect that there is at least a small minority of cases that are not
well served by probe deferral.  (Not to be read as an endorsement of
this specific patch series, just a generic observation.)

-Frank

> other than that you don't care enough to do the real work and are trying
> to hack the driver core up instead.
> 
>> Sorry for the rant,
> 
> No apologies needed, it's cathartic at times :)
> 
> thanks,
> 
> greg k-h
> .
> 

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote:
> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> > <oops, sent too early...>
> > 
> > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> >> But that's moot currently because Greg believes that the time spent
> >> probing devices at boot time could be reduced enough so that the order
> >> in which devices are probed becomes irrelevant. IME that would have to
> >> be under 200ms so that the user doesn't notice and that's unicorn-far
> >> from any bootlog I have ever seen.
> > 
> > But as no one has actually produced a bootlog, how do you know that?
> > Where exactly is your time being spent?  What driver is causing long
> > delays?  Why is the long-delay-drivers not being done in their own
> > thread?  And most importantly, why are you ignoring the work that people
> > did back in 2008 to solve the issue on other hardware platforms?
> > 
> >> Given that downstreams are already carrying as many hacks as they
> >> could think of to speed total boot up, I think this is effectively
> >> telling them to go away.
> > 
> > No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> > solve-the-random-issue-i'm-having type patch by putting random calls in
> > semi-random subsystems all over the kernel.
> > 
> > And when I ask for real data, you respond with the fact that you aren't
> > trying to speed up boot time here at all, so what am I supposed to think
> 
> I also had the understanding that this patch series was about improving
> boot time.  But I was kindly corrected that the behavior change was
> getting the panel displaying stuff at an earlier point in the boot sequence,
> _not_ completing the entire boot faster. 
> 
> The claim for the current series, in patch 0 in v7 is:
> 
>    With this series I get the kernel to output to the panel in 0.5s,
>    instead of 2.8s.
> 
> Just to get side-tracked, one other approach at ordering to reduce
> deferrals reported a modest boot time reduction for four boards and a
> very slight boot time increase for one other board.) The report of boot
> times with that approach was in:
> 
>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
> 
> from Alexander Holler.
> 
> I have not searched further to see if there is more data of boot time
> reductions from any of the other attempts to change driver binding
> order to move dependencies before use of a resource.  But whether
> there is a performance improvement or not, there continues to be
> a stream of developers creatively impacting the binding order for
> their specific driver(s) or board.  So it seems that maybe there
> is an underlying problem, or we don't have adequate documentation
> explaining how to avoid a need to order bindings, or the
> documentation exists and is not being read.
> 
> I have been defaulting to the position that has been asserted by
> the device tree maintainters, that probe deferrals work just fine
> for at least the majority of cases (and is the message I have been
> sharing in my conference presentations about device tree).  But I
> suspect that there is at least a small minority of cases that are not
> well served by probe deferral.  (Not to be read as an endorsement of
> this specific patch series, just a generic observation.)

I agree, there might be some small numbers that this is a problem for,
and if so, great, show us the boot logs where things are taking up all
of the time, and we can work on resolving those issues.

But without hard numbers / details, this all is just random hand-waving,
and I don't like making core kernel changes on that basis.  And no one
else should ever want us to do that either.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote:
> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> > <oops, sent too early...>
> > 
> > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> >> But that's moot currently because Greg believes that the time spent
> >> probing devices at boot time could be reduced enough so that the order
> >> in which devices are probed becomes irrelevant. IME that would have to
> >> be under 200ms so that the user doesn't notice and that's unicorn-far
> >> from any bootlog I have ever seen.
> > 
> > But as no one has actually produced a bootlog, how do you know that?
> > Where exactly is your time being spent?  What driver is causing long
> > delays?  Why is the long-delay-drivers not being done in their own
> > thread?  And most importantly, why are you ignoring the work that people
> > did back in 2008 to solve the issue on other hardware platforms?
> > 
> >> Given that downstreams are already carrying as many hacks as they
> >> could think of to speed total boot up, I think this is effectively
> >> telling them to go away.
> > 
> > No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> > solve-the-random-issue-i'm-having type patch by putting random calls in
> > semi-random subsystems all over the kernel.
> > 
> > And when I ask for real data, you respond with the fact that you aren't
> > trying to speed up boot time here at all, so what am I supposed to think
> 
> I also had the understanding that this patch series was about improving
> boot time.  But I was kindly corrected that the behavior change was
> getting the panel displaying stuff at an earlier point in the boot sequence,
> _not_ completing the entire boot faster. 
> 
> The claim for the current series, in patch 0 in v7 is:
> 
>    With this series I get the kernel to output to the panel in 0.5s,
>    instead of 2.8s.
> 
> Just to get side-tracked, one other approach at ordering to reduce
> deferrals reported a modest boot time reduction for four boards and a
> very slight boot time increase for one other board.) The report of boot
> times with that approach was in:
> 
>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
> 
> from Alexander Holler.
> 
> I have not searched further to see if there is more data of boot time
> reductions from any of the other attempts to change driver binding
> order to move dependencies before use of a resource.  But whether
> there is a performance improvement or not, there continues to be
> a stream of developers creatively impacting the binding order for
> their specific driver(s) or board.  So it seems that maybe there
> is an underlying problem, or we don't have adequate documentation
> explaining how to avoid a need to order bindings, or the
> documentation exists and is not being read.
> 
> I have been defaulting to the position that has been asserted by
> the device tree maintainters, that probe deferrals work just fine
> for at least the majority of cases (and is the message I have been
> sharing in my conference presentations about device tree).  But I
> suspect that there is at least a small minority of cases that are not
> well served by probe deferral.  (Not to be read as an endorsement of
> this specific patch series, just a generic observation.)

I agree, there might be some small numbers that this is a problem for,
and if so, great, show us the boot logs where things are taking up all
of the time, and we can work on resolving those issues.

But without hard numbers / details, this all is just random hand-waving,
and I don't like making core kernel changes on that basis.  And no one
else should ever want us to do that either.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote:
> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> > <oops, sent too early...>
> > 
> > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> >> But that's moot currently because Greg believes that the time spent
> >> probing devices at boot time could be reduced enough so that the order
> >> in which devices are probed becomes irrelevant. IME that would have to
> >> be under 200ms so that the user doesn't notice and that's unicorn-far
> >> from any bootlog I have ever seen.
> > 
> > But as no one has actually produced a bootlog, how do you know that?
> > Where exactly is your time being spent?  What driver is causing long
> > delays?  Why is the long-delay-drivers not being done in their own
> > thread?  And most importantly, why are you ignoring the work that people
> > did back in 2008 to solve the issue on other hardware platforms?
> > 
> >> Given that downstreams are already carrying as many hacks as they
> >> could think of to speed total boot up, I think this is effectively
> >> telling them to go away.
> > 
> > No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> > solve-the-random-issue-i'm-having type patch by putting random calls in
> > semi-random subsystems all over the kernel.
> > 
> > And when I ask for real data, you respond with the fact that you aren't
> > trying to speed up boot time here at all, so what am I supposed to think
> 
> I also had the understanding that this patch series was about improving
> boot time.  But I was kindly corrected that the behavior change was
> getting the panel displaying stuff at an earlier point in the boot sequence,
> _not_ completing the entire boot faster. 
> 
> The claim for the current series, in patch 0 in v7 is:
> 
>    With this series I get the kernel to output to the panel in 0.5s,
>    instead of 2.8s.
> 
> Just to get side-tracked, one other approach at ordering to reduce
> deferrals reported a modest boot time reduction for four boards and a
> very slight boot time increase for one other board.) The report of boot
> times with that approach was in:
> 
>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
> 
> from Alexander Holler.
> 
> I have not searched further to see if there is more data of boot time
> reductions from any of the other attempts to change driver binding
> order to move dependencies before use of a resource.  But whether
> there is a performance improvement or not, there continues to be
> a stream of developers creatively impacting the binding order for
> their specific driver(s) or board.  So it seems that maybe there
> is an underlying problem, or we don't have adequate documentation
> explaining how to avoid a need to order bindings, or the
> documentation exists and is not being read.
> 
> I have been defaulting to the position that has been asserted by
> the device tree maintainters, that probe deferrals work just fine
> for at least the majority of cases (and is the message I have been
> sharing in my conference presentations about device tree).  But I
> suspect that there is at least a small minority of cases that are not
> well served by probe deferral.  (Not to be read as an endorsement of
> this specific patch series, just a generic observation.)

I agree, there might be some small numbers that this is a problem for,
and if so, great, show us the boot logs where things are taking up all
of the time, and we can work on resolving those issues.

But without hard numbers / details, this all is just random hand-waving,
and I don't like making core kernel changes on that basis.  And no one
else should ever want us to do that either.

thanks,

greg k-h

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote:

> If it was such a problem, then in the _eight_ days that this has been
> discussed so far, _someone_ would have sent some data showing the
> problem.  I think the fact is, there is no data.

> Someone prove me wrong.  Someone post the verifiable data showing that
> there is a problem to be solved here.

> Someone show what the specific failure cases are that are hampering
> vendors moving forwards.  Someone show the long boot times by way of
> kernel message log.  Someone show some evidence of the problems that
> have been alluded to.

> If no one can show some evidence, there isn't a problem here. :)

Yeah, I'm not convinced the timing is *such* a big deal either - I do
think that the log spam is a real problem but I think something much
less invasive like the interface you proposed is good for addressing
that.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote:

> If it was such a problem, then in the _eight_ days that this has been
> discussed so far, _someone_ would have sent some data showing the
> problem.  I think the fact is, there is no data.

> Someone prove me wrong.  Someone post the verifiable data showing that
> there is a problem to be solved here.

> Someone show what the specific failure cases are that are hampering
> vendors moving forwards.  Someone show the long boot times by way of
> kernel message log.  Someone show some evidence of the problems that
> have been alluded to.

> If no one can show some evidence, there isn't a problem here. :)

Yeah, I'm not convinced the timing is *such* a big deal either - I do
think that the log spam is a real problem but I think something much
less invasive like the interface you proposed is good for addressing
that.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote:

> If it was such a problem, then in the _eight_ days that this has been
> discussed so far, _someone_ would have sent some data showing the
> problem.  I think the fact is, there is no data.

> Someone prove me wrong.  Someone post the verifiable data showing that
> there is a problem to be solved here.

> Someone show what the specific failure cases are that are hampering
> vendors moving forwards.  Someone show the long boot times by way of
> kernel message log.  Someone show some evidence of the problems that
> have been alluded to.

> If no one can show some evidence, there isn't a problem here. :)

Yeah, I'm not convinced the timing is *such* a big deal either - I do
think that the log spam is a real problem but I think something much
less invasive like the interface you proposed is good for addressing
that.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

[-- Attachment #1: Type: text/plain, Size: 4626 bytes --]

On 10/22/2015 09:26 PM, Greg Kroah-Hartman wrote:
> On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote:
>> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>> <oops, sent too early...>
>>>
>>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>>>> But that's moot currently because Greg believes that the time spent
>>>> probing devices at boot time could be reduced enough so that the order
>>>> in which devices are probed becomes irrelevant. IME that would have to
>>>> be under 200ms so that the user doesn't notice and that's unicorn-far
>>>> from any bootlog I have ever seen.
>>>
>>> But as no one has actually produced a bootlog, how do you know that?
>>> Where exactly is your time being spent?  What driver is causing long
>>> delays?  Why is the long-delay-drivers not being done in their own
>>> thread?  And most importantly, why are you ignoring the work that people
>>> did back in 2008 to solve the issue on other hardware platforms?
>>>
>>>> Given that downstreams are already carrying as many hacks as they
>>>> could think of to speed total boot up, I think this is effectively
>>>> telling them to go away.
>>>
>>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
>>> solve-the-random-issue-i'm-having type patch by putting random calls in
>>> semi-random subsystems all over the kernel.
>>>
>>> And when I ask for real data, you respond with the fact that you aren't
>>> trying to speed up boot time here at all, so what am I supposed to think
>>
>> I also had the understanding that this patch series was about improving
>> boot time.  But I was kindly corrected that the behavior change was
>> getting the panel displaying stuff at an earlier point in the boot sequence,
>> _not_ completing the entire boot faster. 
>>
>> The claim for the current series, in patch 0 in v7 is:
>>
>>    With this series I get the kernel to output to the panel in 0.5s,
>>    instead of 2.8s.
>>
>> Just to get side-tracked, one other approach at ordering to reduce
>> deferrals reported a modest boot time reduction for four boards and a
>> very slight boot time increase for one other board.) The report of boot
>> times with that approach was in:
>>
>>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
>>
>> from Alexander Holler.
>>
>> I have not searched further to see if there is more data of boot time
>> reductions from any of the other attempts to change driver binding
>> order to move dependencies before use of a resource.  But whether
>> there is a performance improvement or not, there continues to be
>> a stream of developers creatively impacting the binding order for
>> their specific driver(s) or board.  So it seems that maybe there
>> is an underlying problem, or we don't have adequate documentation
>> explaining how to avoid a need to order bindings, or the
>> documentation exists and is not being read.
>>
>> I have been defaulting to the position that has been asserted by
>> the device tree maintainters, that probe deferrals work just fine
>> for at least the majority of cases (and is the message I have been
>> sharing in my conference presentations about device tree).  But I
>> suspect that there is at least a small minority of cases that are not
>> well served by probe deferral.  (Not to be read as an endorsement of
>> this specific patch series, just a generic observation.)
> 
> I agree, there might be some small numbers that this is a problem for,
> and if so, great, show us the boot logs where things are taking up all
> of the time, and we can work on resolving those issues.
> 
> But without hard numbers / details, this all is just random hand-waving,
> and I don't like making core kernel changes on that basis.  And no one
> else should ever want us to do that either.

Hi,

have found the board in which Stéphane had the original issue on
(exynos5250-snow), and I'm attaching the bootlog of
next-20151013+exynos_defconfig with initcall_debug and DEBUG in dd.c.

As can be seen, 145b0000.dp-controller is tried reasonably early (at
0.25s), but is deferred and only retried at 0.9s, with the display
finally coming up at 1.35s.

But I'm not sure what's the point in discussing this further if you have
already said that it's fine if downstreams have to change the probing
order by moving files around in the makefiles and by fiddling with
initcall levels.

To give a better understanding of what's going on here, I wasn't
involved in the bringup of this board, but was tasked with fixing this
issue in mainline so it doesn't have to be worked around in every product.

Regards,

Tomeu

> thanks,
> 
> greg k-h
> 


[-- Attachment #2: snow.txt --]
[-- Type: text/plain, Size: 132372 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.3.0-rc5-next-20151013-dirty (tomeu@cizrna) (gcc version 5.2.1 20150716 (Red Hat Cross 5.2.1-3) (GCC) ) #3491 SMP PREEMPT Fri Oct 23 11:17:16 CEST 2015
[    0.000000] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] Machine model: Google Snow
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] cma: Reserved 64 MiB at 0xbc000000
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Samsung CPU ID: 0x43520010
[    0.000000] On node 0 totalpages: 524288
[    0.000000] free_area_init_node: node 0, pgdat c083cc40, node_mem_map eeff7000
[    0.000000]   Normal zone: 1536 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 196608 pages, LIFO batch:31
[    0.000000]   HighMem zone: 327680 pages, LIFO batch:31
[    0.000000] PERCPU: Embedded 12 pages/cpu @eefa7000 s18880 r8192 d22080 u49152
[    0.000000] pcpu-alloc: s18880 r8192 d22080 u49152 alloc=12*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 522752
[    0.000000] Kernel command line: console=tty1 initcall_debug rw rootwait root=/dev/nfs nfsroot=10.42.0.1:/home/tomeu/nfsroot,vers=3 ip=dhcp ignore_loglevel log_buf_len=16M drm.debug=0x00 no_console_suspend
[    0.000000] log_buf_len: 16777216 bytes
[    0.000000] early log buf free: 129580(98%)
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 1988920K/2097152K available (5722K kernel code, 238K rwdata, 2016K rodata, 428K init, 315K bss, 42696K reserved, 65536K cma-reserved, 1245184K highmem)
[    0.000000] Virtual kernel memory layout:
                   vector  : 0xffff0000 - 0xffff1000   (   4 kB)
                   fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
                   vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
                   lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
                   pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
                   modules : 0xbf000000 - 0xbfe00000   (  14 MB)
                     .text : 0xc0008000 - 0xc0796ad4   (7739 kB)
                     .init : 0xc0797000 - 0xc0802000   ( 428 kB)
                     .data : 0xc0802000 - 0xc083dbc0   ( 239 kB)
                      .bss : 0xc0840000 - 0xc088ec90   ( 316 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] 	Build-time adjustment of leaf fanout to 32.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] GIC physical location is 0x10481000
[    0.000000] L2C: failed to init: -19
[    0.000000] Exynos5250: clock setup completed, armclk=1700000000
[    0.000000] Architected cp15 timer(s) running at 24.00MHz (virt).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[    0.000002] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
[    0.000009] Switching to timer-based delay loop, resolution 41ns
[    0.000170] Ignoring duplicate/late registration of read_current_timer delay
[    0.000178] clocksource: mct-frc: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[    0.000187] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
[    0.000484] Console: colour dummy device 80x30
[    0.000824] console [tty1] enabled
[    0.000838] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=120000)
[    0.000858] pid_max: default: 32768 minimum: 301
[    0.000937] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000950] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.001289] CPU: Testing write buffer coherency: ok
[    0.001421] CPU0: update cpu_capacity 1024
[    0.001433] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.001492] calling  cpu_suspend_alloc_sp+0x0/0x9c @ 1
[    0.001507] initcall cpu_suspend_alloc_sp+0x0/0x9c returned 0 after 0 usecs
[    0.001527] calling  init_static_idmap+0x0/0x114 @ 1
[    0.001545] Setting up static identity map for 0x40008280 - 0x400082d8
[    0.001564] initcall init_static_idmap+0x0/0x114 returned 0 after 0 usecs
[    0.001583] calling  exynos_mcpm_init+0x0/0x168 @ 1
[    0.001729] initcall exynos_mcpm_init+0x0/0x168 returned -19 after 0 usecs
[    0.001747] calling  spawn_ksoftirqd+0x0/0x34 @ 1
[    0.004936] initcall spawn_ksoftirqd+0x0/0x34 returned 0 after 4882 usecs
[    0.004955] calling  init_workqueues+0x0/0x3dc @ 1
[    0.019997] initcall init_workqueues+0x0/0x3dc returned 0 after 14648 usecs
[    0.020016] calling  migration_init+0x0/0x6c @ 1
[    0.020034] initcall migration_init+0x0/0x6c returned 0 after 0 usecs
[    0.020049] calling  check_cpu_stall_init+0x0/0x20 @ 1
[    0.020062] initcall check_cpu_stall_init+0x0/0x20 returned 0 after 0 usecs
[    0.020077] calling  rcu_spawn_gp_kthread+0x0/0x104 @ 1
[    0.020195] initcall rcu_spawn_gp_kthread+0x0/0x104 returned 0 after 0 usecs
[    0.020213] calling  cpu_stop_init+0x0/0xac @ 1
[    0.024982] initcall cpu_stop_init+0x0/0xac returned 0 after 4882 usecs
[    0.025000] calling  cci_init+0x0/0x18 @ 1
[    0.025080] initcall cci_init+0x0/0x18 returned -19 after 0 usecs
[    0.025098] calling  rand_initialize+0x0/0x2c @ 1
[    0.025214] initcall rand_initialize+0x0/0x2c returned 0 after 0 usecs
[    0.025232] calling  dummy_timer_register+0x0/0x48 @ 1
[    0.025247] initcall dummy_timer_register+0x0/0x48 returned 0 after 0 usecs
[    0.045065] CPU1: update cpu_capacity 1024
[    0.045069] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.045119] Brought up 2 CPUs
[    0.045146] SMP: Total of 2 processors activated (96.00 BogoMIPS).
[    0.045156] CPU: All CPU(s) started in SVC mode.
[    0.045767] devtmpfs: initialized
[    0.055547] calling  ipc_ns_init+0x0/0x3c @ 1
[    0.055566] initcall ipc_ns_init+0x0/0x3c returned 0 after 0 usecs
[    0.055580] calling  init_mmap_min_addr+0x0/0x20 @ 1
[    0.055592] initcall init_mmap_min_addr+0x0/0x20 returned 0 after 0 usecs
[    0.055608] calling  init_cpufreq_transition_notifier_list+0x0/0x24 @ 1
[    0.055625] initcall init_cpufreq_transition_notifier_list+0x0/0x24 returned 0 after 0 usecs
[    0.055647] calling  net_ns_init+0x0/0x14c @ 1
[    0.055754] initcall net_ns_init+0x0/0x14c returned 0 after 0 usecs
[    0.055833] calling  vfp_init+0x0/0x1b8 @ 1
[    0.055847] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
[    0.055871] initcall vfp_init+0x0/0x1b8 returned 0 after 0 usecs
[    0.055885] calling  ptrace_break_init+0x0/0x2c @ 1
[    0.055898] initcall ptrace_break_init+0x0/0x2c returned 0 after 0 usecs
[    0.055913] calling  register_cpufreq_notifier+0x0/0x10 @ 1
[    0.055926] initcall register_cpufreq_notifier+0x0/0x10 returned 0 after 0 usecs
[    0.055945] calling  v6_userpage_init+0x0/0x8 @ 1
[    0.055957] initcall v6_userpage_init+0x0/0x8 returned 0 after 0 usecs
[    0.055973] calling  exynos4_pm_init_power_domain+0x0/0x2e0 @ 1
[    0.056176] initcall exynos4_pm_init_power_domain+0x0/0x2e0 returned 0 after 0 usecs
[    0.056197] calling  cpu_hotplug_pm_sync_init+0x0/0x18 @ 1
[    0.056210] initcall cpu_hotplug_pm_sync_init+0x0/0x18 returned 0 after 0 usecs
[    0.056230] calling  alloc_frozen_cpus+0x0/0x8 @ 1
[    0.056241] initcall alloc_frozen_cpus+0x0/0x8 returned 0 after 0 usecs
[    0.056257] calling  wq_sysfs_init+0x0/0x30 @ 1
[    0.056444] initcall wq_sysfs_init+0x0/0x30 returned 0 after 0 usecs
[    0.056462] calling  ksysfs_init+0x0/0xa4 @ 1
[    0.056494] initcall ksysfs_init+0x0/0xa4 returned 0 after 0 usecs
[    0.056511] calling  pm_init+0x0/0x78 @ 1
[    0.056565] initcall pm_init+0x0/0x78 returned 0 after 0 usecs
[    0.056579] calling  init_jiffies_clocksource+0x0/0x14 @ 1
[    0.056592] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302231375000 ns
[    0.056610] initcall init_jiffies_clocksource+0x0/0x14 returned 0 after 0 usecs
[    0.056628] calling  cgroup_wq_init+0x0/0x80 @ 1
[    0.056665] initcall cgroup_wq_init+0x0/0x80 returned 0 after 0 usecs
[    0.056680] calling  cpu_pm_init+0x0/0x18 @ 1
[    0.056692] initcall cpu_pm_init+0x0/0x18 returned 0 after 0 usecs
[    0.056707] calling  init_zero_pfn+0x0/0x40 @ 1
[    0.056718] initcall init_zero_pfn+0x0/0x40 returned 0 after 0 usecs
[    0.056734] calling  cma_init_reserved_areas+0x0/0x1d4 @ 1
[    0.057256] initcall cma_init_reserved_areas+0x0/0x1d4 returned 0 after 0 usecs
[    0.057278] calling  fsnotify_init+0x0/0x24 @ 1
[    0.057294] initcall fsnotify_init+0x0/0x24 returned 0 after 0 usecs
[    0.057310] calling  filelock_init+0x0/0xc4 @ 1
[    0.057335] initcall filelock_init+0x0/0xc4 returned 0 after 0 usecs
[    0.057351] calling  init_script_binfmt+0x0/0x1c @ 1
[    0.057364] initcall init_script_binfmt+0x0/0x1c returned 0 after 0 usecs
[    0.057379] calling  init_elf_binfmt+0x0/0x1c @ 1
[    0.057391] initcall init_elf_binfmt+0x0/0x1c returned 0 after 0 usecs
[    0.057407] calling  configfs_init+0x0/0xb0 @ 1
[    0.057437] initcall configfs_init+0x0/0xb0 returned 0 after 0 usecs
[    0.057451] calling  debugfs_init+0x0/0x68 @ 1
[    0.057467] initcall debugfs_init+0x0/0x68 returned 0 after 0 usecs
[    0.057480] calling  securityfs_init+0x0/0x58 @ 1
[    0.057495] initcall securityfs_init+0x0/0x58 returned 0 after 0 usecs
[    0.057509] calling  prandom_init+0x0/0xe4 @ 1
[    0.057521] initcall prandom_init+0x0/0xe4 returned 0 after 0 usecs
[    0.057535] calling  cci_platform_init+0x0/0x8 @ 1
[    0.057546] initcall cci_platform_init+0x0/0x8 returned 0 after 0 usecs
[    0.057560] calling  pinctrl_init+0x0/0xd4 @ 1
[    0.057569] pinctrl core: initialized pinctrl subsystem
[    0.057622] initcall pinctrl_init+0x0/0xd4 returned 0 after 0 usecs
[    0.057638] calling  regulator_init+0x0/0xa4 @ 1
[    0.057836] bus: 'platform': driver_probe_device: matched device reg-dummy with driver reg-dummy
[    0.057855] bus: 'platform': really_probe: probing driver reg-dummy with device reg-dummy
[    0.058019] driver: 'reg-dummy': driver_bound: bound to device 'reg-dummy'
[    0.058033] bus: 'platform': really_probe: bound device reg-dummy to driver reg-dummy
[    0.058097] initcall regulator_init+0x0/0xa4 returned 0 after 0 usecs
[    0.058114] calling  cpufreq_core_init+0x0/0x50 @ 1
[    0.058126] initcall cpufreq_core_init+0x0/0x50 returned 0 after 0 usecs
[    0.058140] calling  cpuidle_init+0x0/0x58 @ 1
[    0.058163] initcall cpuidle_init+0x0/0x58 returned 0 after 0 usecs
[    0.058177] calling  cpuidle_coupled_init+0x0/0xc @ 1
[    0.058190] initcall cpuidle_coupled_init+0x0/0xc returned 0 after 0 usecs
[    0.058207] calling  exynos_audss_clk_init+0x0/0x10 @ 1
[    0.058265] initcall exynos_audss_clk_init+0x0/0x10 returned 0 after 0 usecs
[    0.058282] calling  sock_init+0x0/0x94 @ 1
[    0.058334] initcall sock_init+0x0/0x94 returned 0 after 0 usecs
[    0.058351] calling  net_inuse_init+0x0/0x24 @ 1
[    0.058365] initcall net_inuse_init+0x0/0x24 returned 0 after 0 usecs
[    0.058379] calling  netlink_proto_init+0x0/0x148 @ 1
[    0.058490] NET: Registered protocol family 16
[    0.058519] initcall netlink_proto_init+0x0/0x148 returned 0 after 0 usecs
[    0.058604] calling  atomic_pool_init+0x0/0x168 @ 1
[    0.059145] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.059160] initcall atomic_pool_init+0x0/0x168 returned 0 after 0 usecs
[    0.059177] calling  exynos_pmu_init+0x0/0x10 @ 1
[    0.059247] initcall exynos_pmu_init+0x0/0x10 returned 0 after 0 usecs
[    0.059265] calling  bdi_class_init+0x0/0x5c @ 1
[    0.059317] initcall bdi_class_init+0x0/0x5c returned 0 after 0 usecs
[    0.059333] calling  mm_sysfs_init+0x0/0x38 @ 1
[    0.059349] initcall mm_sysfs_init+0x0/0x38 returned 0 after 0 usecs
[    0.059364] calling  kobject_uevent_init+0x0/0xc @ 1
[    0.059383] initcall kobject_uevent_init+0x0/0xc returned 0 after 0 usecs
[    0.059398] calling  samsung_pinctrl_drv_register+0x0/0x24 @ 1
[    0.059457] initcall samsung_pinctrl_drv_register+0x0/0x24 returned 0 after 0 usecs
[    0.059477] calling  exynos5440_pinctrl_drv_register+0x0/0x10 @ 1
[    0.059533] initcall exynos5440_pinctrl_drv_register+0x0/0x10 returned 0 after 0 usecs
[    0.059553] calling  lcd_class_init+0x0/0x58 @ 1
[    0.059601] initcall lcd_class_init+0x0/0x58 returned 0 after 0 usecs
[    0.059616] calling  backlight_class_init+0x0/0xa4 @ 1
[    0.059661] initcall backlight_class_init+0x0/0xa4 returned 0 after 0 usecs
[    0.059677] calling  amba_init+0x0/0xc @ 1
[    0.059741] initcall amba_init+0x0/0xc returned 0 after 0 usecs
[    0.059757] calling  tty_class_init+0x0/0x40 @ 1
[    0.059800] initcall tty_class_init+0x0/0x40 returned 0 after 0 usecs
[    0.059817] calling  vtconsole_class_init+0x0/0xec @ 1
[    0.059947] initcall vtconsole_class_init+0x0/0xec returned 0 after 0 usecs
[    0.059965] calling  mipi_dsi_bus_init+0x0/0xc @ 1
[    0.060052] initcall mipi_dsi_bus_init+0x0/0xc returned 0 after 4882 usecs
[    0.060070] calling  wakeup_sources_debugfs_init+0x0/0x38 @ 1
[    0.060104] initcall wakeup_sources_debugfs_init+0x0/0x38 returned 0 after 0 usecs
[    0.060123] calling  regmap_initcall+0x0/0x10 @ 1
[    0.060141] initcall regmap_initcall+0x0/0x10 returned 0 after 0 usecs
[    0.060157] calling  sram_init+0x0/0x10 @ 1
[    0.060218] initcall sram_init+0x0/0x10 returned 0 after 0 usecs
[    0.060235] calling  syscon_init+0x0/0x10 @ 1
[    0.060291] initcall syscon_init+0x0/0x10 returned 0 after 0 usecs
[    0.060307] calling  spi_init+0x0/0x94 @ 1
[    0.060403] initcall spi_init+0x0/0x94 returned 0 after 0 usecs
[    0.060418] calling  i2c_init+0x0/0xb8 @ 1
[    0.060538] initcall i2c_init+0x0/0xb8 returned 0 after 0 usecs
[    0.060553] calling  init_ladder+0x0/0xc @ 1
[    0.075090] cpuidle: using governor ladder
[    0.075103] initcall init_ladder+0x0/0xc returned 0 after 14648 usecs
[    0.075116] calling  init_menu+0x0/0xc @ 1
[    0.095118] cpuidle: using governor menu
[    0.095131] initcall init_menu+0x0/0xc returned 0 after 19531 usecs
[    0.095207] calling  gate_vma_init+0x0/0x24 @ 1
[    0.095219] initcall gate_vma_init+0x0/0x24 returned 0 after 0 usecs
[    0.095233] calling  customize_machine+0x0/0x40 @ 1
[    0.097232] bus: 'platform': driver_probe_device: matched device 2020000.sysram with driver sram
[    0.097251] bus: 'platform': really_probe: probing driver sram with device 2020000.sysram
[    0.097318] driver: 'sram': driver_bound: bound to device '2020000.sysram'
[    0.097332] bus: 'platform': really_probe: bound device 2020000.sysram to driver sram
[    0.097885] bus: 'platform': driver_probe_device: matched device 3810000.audss-clock-controller with driver exynos-audss-clk
[    0.097903] bus: 'platform': really_probe: probing driver exynos-audss-clk with device 3810000.audss-clock-controller
[    0.098183] exynos-audss-clk 3810000.audss-clock-controller: setup completed
[    0.098197] driver: 'exynos-audss-clk': driver_bound: bound to device '3810000.audss-clock-controller'
[    0.098213] bus: 'platform': really_probe: bound device 3810000.audss-clock-controller to driver exynos-audss-clk
[    0.098911] bus: 'platform': driver_probe_device: matched device 11400000.pinctrl with driver samsung-pinctrl
[    0.098929] bus: 'platform': really_probe: probing driver samsung-pinctrl with device 11400000.pinctrl
[    0.099063] gpiochip_add: registered GPIOs 0 to 7 on device: gpa0
[    0.099077] gpiochip_add: registered GPIOs 8 to 13 on device: gpa1
[    0.099090] gpiochip_add: registered GPIOs 14 to 21 on device: gpa2
[    0.099102] gpiochip_add: registered GPIOs 22 to 26 on device: gpb0
[    0.099114] gpiochip_add: registered GPIOs 27 to 31 on device: gpb1
[    0.099127] gpiochip_add: registered GPIOs 32 to 35 on device: gpb2
[    0.099138] gpiochip_add: registered GPIOs 36 to 39 on device: gpb3
[    0.099150] gpiochip_add: registered GPIOs 40 to 46 on device: gpc0
[    0.099162] gpiochip_add: registered GPIOs 47 to 50 on device: gpc1
[    0.099177] gpiochip_add: registered GPIOs 51 to 57 on device: gpc2
[    0.099188] gpiochip_add: registered GPIOs 58 to 64 on device: gpc3
[    0.099201] gpiochip_add: registered GPIOs 65 to 68 on device: gpd0
[    0.099213] gpiochip_add: registered GPIOs 69 to 76 on device: gpd1
[    0.099225] gpiochip_add: registered GPIOs 77 to 83 on device: gpc4
[    0.099237] gpiochip_add: registered GPIOs 84 to 89 on device: gpy0
[    0.099249] gpiochip_add: registered GPIOs 90 to 93 on device: gpy1
[    0.099261] gpiochip_add: registered GPIOs 94 to 99 on device: gpy2
[    0.099274] gpiochip_add: registered GPIOs 100 to 107 on device: gpy3
[    0.099286] gpiochip_add: registered GPIOs 108 to 115 on device: gpy4
[    0.099298] gpiochip_add: registered GPIOs 116 to 123 on device: gpy5
[    0.099311] gpiochip_add: registered GPIOs 124 to 131 on device: gpy6
[    0.099323] gpiochip_add: registered GPIOs 132 to 139 on device: gpx0
[    0.099336] gpiochip_add: registered GPIOs 140 to 147 on device: gpx1
[    0.099348] gpiochip_add: registered GPIOs 148 to 155 on device: gpx2
[    0.099360] gpiochip_add: registered GPIOs 156 to 163 on device: gpx3
[    0.100001] driver: 'samsung-pinctrl': driver_bound: bound to device '11400000.pinctrl'
[    0.100019] bus: 'platform': really_probe: bound device 11400000.pinctrl to driver samsung-pinctrl
[    0.100207] bus: 'platform': driver_probe_device: matched device 13400000.pinctrl with driver samsung-pinctrl
[    0.100225] bus: 'platform': really_probe: probing driver samsung-pinctrl with device 13400000.pinctrl
[    0.100290] gpiochip_add: registered GPIOs 164 to 171 on device: gpe0
[    0.100304] gpiochip_add: registered GPIOs 172 to 173 on device: gpe1
[    0.100317] gpiochip_add: registered GPIOs 174 to 177 on device: gpf0
[    0.100330] gpiochip_add: registered GPIOs 178 to 181 on device: gpf1
[    0.100342] gpiochip_add: registered GPIOs 182 to 189 on device: gpg0
[    0.100355] gpiochip_add: registered GPIOs 190 to 197 on device: gpg1
[    0.100367] gpiochip_add: registered GPIOs 198 to 199 on device: gpg2
[    0.100379] gpiochip_add: registered GPIOs 200 to 203 on device: gph0
[    0.100392] gpiochip_add: registered GPIOs 204 to 211 on device: gph1
[    0.100580] driver: 'samsung-pinctrl': driver_bound: bound to device '13400000.pinctrl'
[    0.100597] bus: 'platform': really_probe: bound device 13400000.pinctrl to driver samsung-pinctrl
[    0.100751] bus: 'platform': driver_probe_device: matched device 10d10000.pinctrl with driver samsung-pinctrl
[    0.100769] bus: 'platform': really_probe: probing driver samsung-pinctrl with device 10d10000.pinctrl
[    0.100825] gpiochip_add: registered GPIOs 212 to 219 on device: gpv0
[    0.100838] gpiochip_add: registered GPIOs 220 to 227 on device: gpv1
[    0.100851] gpiochip_add: registered GPIOs 228 to 235 on device: gpv2
[    0.100863] gpiochip_add: registered GPIOs 236 to 243 on device: gpv3
[    0.100876] gpiochip_add: registered GPIOs 244 to 245 on device: gpv4
[    0.101006] driver: 'samsung-pinctrl': driver_bound: bound to device '10d10000.pinctrl'
[    0.101023] bus: 'platform': really_probe: bound device 10d10000.pinctrl to driver samsung-pinctrl
[    0.101175] bus: 'platform': driver_probe_device: matched device 3860000.pinctrl with driver samsung-pinctrl
[    0.101192] bus: 'platform': really_probe: probing driver samsung-pinctrl with device 3860000.pinctrl
[    0.101237] gpiochip_add: registered GPIOs 246 to 252 on device: gpz
[    0.101330] driver: 'samsung-pinctrl': driver_bound: bound to device '3860000.pinctrl'
[    0.101347] bus: 'platform': really_probe: bound device 3860000.pinctrl to driver samsung-pinctrl
[    0.101472] bus: 'platform': driver_probe_device: matched device 10040000.system-controller with driver exynos-pmu
[    0.101490] bus: 'platform': really_probe: probing driver exynos-pmu with device 10040000.system-controller
[    0.101531] driver: 'exynos-pmu': driver_bound: bound to device '10040000.system-controller'
[    0.101547] bus: 'platform': really_probe: bound device 10040000.system-controller to driver exynos-pmu
[    0.109998] initcall customize_machine+0x0/0x40 returned 0 after 9765 usecs
[    0.110020] calling  vdso_init+0x0/0x1a4 @ 1
[    0.110049] initcall vdso_init+0x0/0x1a4 returned 0 after 0 usecs
[    0.110064] calling  exceptions_init+0x0/0x9c @ 1
[    0.110077] initcall exceptions_init+0x0/0x9c returned 0 after 0 usecs
[    0.110093] calling  s3c_arch_init+0x0/0x40 @ 1
[    0.110106] initcall s3c_arch_init+0x0/0x40 returned 0 after 0 usecs
[    0.110121] calling  dma_bus_init+0x0/0xa8 @ 1
[    0.110212] initcall dma_bus_init+0x0/0xa8 returned 0 after 0 usecs
[    0.110230] calling  dma_channel_table_init+0x0/0xf0 @ 1
[    0.110255] initcall dma_channel_table_init+0x0/0xf0 returned 0 after 0 usecs
[    0.110337] calling  topology_init+0x0/0x74 @ 1
[    0.110517] initcall topology_init+0x0/0x74 returned 0 after 0 usecs
[    0.110535] calling  uid_cache_init+0x0/0xa4 @ 1
[    0.110550] initcall uid_cache_init+0x0/0xa4 returned 0 after 0 usecs
[    0.110567] calling  param_sysfs_init+0x0/0x1d8 @ 1
[    0.119328] initcall param_sysfs_init+0x0/0x1d8 returned 0 after 4882 usecs
[    0.119354] calling  pm_sysrq_init+0x0/0x1c @ 1
[    0.130217] initcall pm_sysrq_init+0x0/0x1c returned 0 after 14648 usecs
[    0.130237] calling  hung_task_init+0x0/0x58 @ 1
[    0.130296] initcall hung_task_init+0x0/0x58 returned 0 after 0 usecs
[    0.130312] calling  default_bdi_init+0x0/0x58 @ 1
[    0.130493] initcall default_bdi_init+0x0/0x58 returned 0 after 0 usecs
[    0.130510] calling  percpu_enable_async+0x0/0x18 @ 1
[    0.130522] initcall percpu_enable_async+0x0/0x18 returned 0 after 0 usecs
[    0.130539] calling  init_reserve_notifier+0x0/0x8 @ 1
[    0.130552] initcall init_reserve_notifier+0x0/0x8 returned 0 after 0 usecs
[    0.130573] calling  init_admin_reserve+0x0/0x30 @ 1
[    0.130586] initcall init_admin_reserve+0x0/0x30 returned 0 after 0 usecs
[    0.130602] calling  init_user_reserve+0x0/0x30 @ 1
[    0.130614] initcall init_user_reserve+0x0/0x30 returned 0 after 0 usecs
[    0.130628] calling  crypto_wq_init+0x0/0x44 @ 1
[    0.130696] initcall crypto_wq_init+0x0/0x44 returned 0 after 0 usecs
[    0.130711] calling  cryptomgr_init+0x0/0xc @ 1
[    0.130722] initcall cryptomgr_init+0x0/0xc returned 0 after 0 usecs
[    0.130735] calling  init_bio+0x0/0xc0 @ 1
[    0.130824] initcall init_bio+0x0/0xc0 returned 0 after 0 usecs
[    0.130839] calling  blk_settings_init+0x0/0x38 @ 1
[    0.130850] initcall blk_settings_init+0x0/0x38 returned 0 after 0 usecs
[    0.130863] calling  blk_ioc_init+0x0/0x40 @ 1
[    0.130877] initcall blk_ioc_init+0x0/0x40 returned 0 after 0 usecs
[    0.130890] calling  blk_softirq_init+0x0/0x80 @ 1
[    0.130903] initcall blk_softirq_init+0x0/0x80 returned 0 after 0 usecs
[    0.130917] calling  blk_iopoll_setup+0x0/0x80 @ 1
[    0.130928] initcall blk_iopoll_setup+0x0/0x80 returned 0 after 0 usecs
[    0.130941] calling  blk_mq_init+0x0/0x1c @ 1
[    0.130953] initcall blk_mq_init+0x0/0x1c returned 0 after 0 usecs
[    0.130967] calling  genhd_device_init+0x0/0x80 @ 1
[    0.131085] initcall genhd_device_init+0x0/0x80 returned 0 after 0 usecs
[    0.131102] calling  gpiolib_debugfs_init+0x0/0x38 @ 1
[    0.131123] initcall gpiolib_debugfs_init+0x0/0x38 returned 0 after 0 usecs
[    0.131138] calling  pwm_debugfs_init+0x0/0x38 @ 1
[    0.131153] initcall pwm_debugfs_init+0x0/0x38 returned 0 after 0 usecs
[    0.131168] calling  pwm_sysfs_init+0x0/0x14 @ 1
[    0.131215] initcall pwm_sysfs_init+0x0/0x14 returned 0 after 0 usecs
[    0.131230] calling  fbmem_init+0x0/0xb4 @ 1
[    0.131285] initcall fbmem_init+0x0/0xb4 returned 0 after 0 usecs
[    0.131302] calling  regulator_fixed_voltage_init+0x0/0x10 @ 1
[    0.131427] bus: 'platform': driver_probe_device: matched device vbat-fixed-regulator with driver reg-fixed-voltage
[    0.131445] bus: 'platform': really_probe: probing driver reg-fixed-voltage with device vbat-fixed-regulator
[    0.131498] of_get_named_gpiod_flags: can't parse 'gpio' property of node '/vbat-fixed-regulator[0]'
[    0.131664] driver: 'reg-fixed-voltage': driver_bound: bound to device 'vbat-fixed-regulator'
[    0.131682] bus: 'platform': really_probe: bound device vbat-fixed-regulator to driver reg-fixed-voltage
[    0.131704] bus: 'platform': driver_probe_device: matched device regulator-usb3 with driver reg-fixed-voltage
[    0.131722] bus: 'platform': really_probe: probing driver reg-fixed-voltage with device regulator-usb3
[    0.131832] of_get_named_gpiod_flags: parsed 'gpio' property of node '/regulator-usb3[0]' - status (0)
[    0.132003] driver: 'reg-fixed-voltage': driver_bound: bound to device 'regulator-usb3'
[    0.132021] bus: 'platform': really_probe: bound device regulator-usb3 to driver reg-fixed-voltage
[    0.132089] initcall regulator_fixed_voltage_init+0x0/0x10 returned 0 after 0 usecs
[    0.132109] calling  gpio_regulator_init+0x0/0x10 @ 1
[    0.132241] initcall gpio_regulator_init+0x0/0x10 returned 0 after 0 usecs
[    0.132258] calling  max14577_regulator_init+0x0/0x10 @ 1
[    0.132344] initcall max14577_regulator_init+0x0/0x10 returned 0 after 0 usecs
[    0.132364] calling  max8997_pmic_init+0x0/0x10 @ 1
[    0.132445] initcall max8997_pmic_init+0x0/0x10 returned 0 after 0 usecs
[    0.132461] calling  max77686_pmic_init+0x0/0x10 @ 1
[    0.132548] initcall max77686_pmic_init+0x0/0x10 returned 0 after 0 usecs
[    0.132564] calling  max77693_pmic_init+0x0/0x10 @ 1
[    0.132650] initcall max77693_pmic_init+0x0/0x10 returned 0 after 0 usecs
[    0.132666] calling  s2mps11_pmic_init+0x0/0x10 @ 1
[    0.132751] initcall s2mps11_pmic_init+0x0/0x10 returned 0 after 0 usecs
[    0.132767] calling  s5m8767_pmic_init+0x0/0x10 @ 1
[    0.132850] initcall s5m8767_pmic_init+0x0/0x10 returned 0 after 0 usecs
[    0.132866] calling  tps65090_regulator_init+0x0/0x10 @ 1
[    0.132952] initcall tps65090_regulator_init+0x0/0x10 returned 0 after 0 usecs
[    0.132972] calling  misc_init+0x0/0xe0 @ 1
[    0.133025] initcall misc_init+0x0/0xe0 returned 0 after 0 usecs
[    0.133040] calling  tpm_init+0x0/0x8c @ 1
[    0.133086] initcall tpm_init+0x0/0x8c returned 0 after 0 usecs
[    0.133104] calling  max14577_i2c_init+0x0/0x10 @ 1
[    0.133160] initcall max14577_i2c_init+0x0/0x10 returned 0 after 0 usecs
[    0.133177] calling  max77686_i2c_init+0x0/0x10 @ 1
[    0.133232] initcall max77686_i2c_init+0x0/0x10 returned 0 after 0 usecs
[    0.133249] calling  max77693_i2c_init+0x0/0x10 @ 1
[    0.133303] initcall max77693_i2c_init+0x0/0x10 returned 0 after 0 usecs
[    0.133320] calling  max8997_i2c_init+0x0/0x10 @ 1
[    0.133375] initcall max8997_i2c_init+0x0/0x10 returned 0 after 0 usecs
[    0.133392] calling  tps65090_init+0x0/0x10 @ 1
[    0.133447] initcall tps65090_init+0x0/0x10 returned 0 after 0 usecs
[    0.133463] calling  sec_pmic_init+0x0/0x10 @ 1
[    0.133518] initcall sec_pmic_init+0x0/0x10 returned 0 after 0 usecs
[    0.133534] calling  dma_buf_init+0x0/0x84 @ 1
[    0.133555] initcall dma_buf_init+0x0/0x84 returned 0 after 0 usecs
[    0.133571] calling  init_scsi+0x0/0x8c @ 1
[    0.133795] SCSI subsystem initialized
[    0.133810] initcall init_scsi+0x0/0x8c returned 0 after 0 usecs
[    0.133826] calling  phy_init+0x0/0x3c @ 1
[    0.134005] initcall phy_init+0x0/0x3c returned 0 after 0 usecs
[    0.134022] calling  usb_init+0x0/0x17c @ 1
[    0.134159] usbcore: registered new interface driver usbfs
[    0.134230] usbcore: registered new interface driver hub
[    0.134308] usbcore: registered new device driver usb
[    0.134322] initcall usb_init+0x0/0x17c returned 0 after 0 usecs
[    0.134339] calling  usb_udc_init+0x0/0x58 @ 1
[    0.134384] initcall usb_udc_init+0x0/0x58 returned 0 after 0 usecs
[    0.134398] calling  serio_init+0x0/0x30 @ 1
[    0.134459] initcall serio_init+0x0/0x30 returned 0 after 0 usecs
[    0.134473] calling  input_init+0x0/0x11c @ 1
[    0.134525] initcall input_init+0x0/0x11c returned 0 after 0 usecs
[    0.134539] calling  rtc_init+0x0/0x58 @ 1
[    0.134584] initcall rtc_init+0x0/0x58 returned 0 after 0 usecs
[    0.134598] calling  i2c_gpio_init+0x0/0x34 @ 1
[    0.134740] initcall i2c_gpio_init+0x0/0x34 returned 0 after 0 usecs
[    0.134754] calling  i2c_adap_s3c_init+0x0/0x10 @ 1
[    0.134821] bus: 'platform': driver_probe_device: matched device 12c60000.i2c with driver s3c-i2c
[    0.134838] bus: 'platform': really_probe: probing driver s3c-i2c with device 12c60000.i2c
[    0.134973] s3c-i2c 12c60000.i2c: slave address 0x00
[    0.134988] s3c-i2c 12c60000.i2c: bus frequency set to 378 KHz
[    0.135315] bus: 'i2c': driver_probe_device: matched device 0-0009 with driver max77686
[    0.135335] bus: 'i2c': really_probe: probing driver max77686 with device 0-0009
[    0.135750] bus: 'i2c': driver_probe_device: matched device 0-0006 with driver dummy
[    0.135769] bus: 'i2c': really_probe: probing driver dummy with device 0-0006
[    0.135796] driver: 'dummy': driver_bound: bound to device '0-0006'
[    0.135808] bus: 'i2c': really_probe: bound device 0-0006 to driver dummy
[    0.136613] bus: 'platform': driver_probe_device: matched device max77686-pmic with driver max77686-pmic
[    0.136631] bus: 'platform': really_probe: probing driver max77686-pmic with device max77686-pmic
[    0.155437] of_get_named_gpiod_flags: can't parse 'maxim,ena-gpios' property of node '/i2c@12C60000/max77686@09/voltage-regulators/BUCK8[0]'
[    0.156487] driver: 'max77686-pmic': driver_bound: bound to device 'max77686-pmic'
[    0.156505] bus: 'platform': really_probe: bound device max77686-pmic to driver max77686-pmic
[    0.156702] driver: 'max77686': driver_bound: bound to device '0-0009'
[    0.156715] bus: 'i2c': really_probe: bound device 0-0009 to driver max77686
[    0.156737] s3c-i2c 12c60000.i2c: i2c-0: S3C I2C adapter
[    0.156748] driver: 's3c-i2c': driver_bound: bound to device '12c60000.i2c'
[    0.156760] bus: 'platform': really_probe: bound device 12c60000.i2c to driver s3c-i2c
[    0.156781] bus: 'platform': driver_probe_device: matched device 12c70000.i2c with driver s3c-i2c
[    0.156797] bus: 'platform': really_probe: probing driver s3c-i2c with device 12c70000.i2c
[    0.156922] s3c-i2c 12c70000.i2c: slave address 0x00
[    0.156937] s3c-i2c 12c70000.i2c: bus frequency set to 378 KHz
[    0.157205] s3c-i2c 12c70000.i2c: i2c-1: S3C I2C adapter
[    0.157218] driver: 's3c-i2c': driver_bound: bound to device '12c70000.i2c'
[    0.157231] bus: 'platform': really_probe: bound device 12c70000.i2c to driver s3c-i2c
[    0.157251] bus: 'platform': driver_probe_device: matched device 12c80000.i2c with driver s3c-i2c
[    0.157267] bus: 'platform': really_probe: probing driver s3c-i2c with device 12c80000.i2c
[    0.157352] s3c-i2c 12c80000.i2c: slave address 0x00
[    0.157366] s3c-i2c 12c80000.i2c: bus frequency set to 65 KHz
[    0.157617] s3c-i2c 12c80000.i2c: i2c-2: S3C I2C adapter
[    0.157629] driver: 's3c-i2c': driver_bound: bound to device '12c80000.i2c'
[    0.157641] bus: 'platform': really_probe: bound device 12c80000.i2c to driver s3c-i2c
[    0.157660] bus: 'platform': driver_probe_device: matched device 12c90000.i2c with driver s3c-i2c
[    0.157676] bus: 'platform': really_probe: probing driver s3c-i2c with device 12c90000.i2c
[    0.157763] s3c-i2c 12c90000.i2c: slave address 0x00
[    0.157776] s3c-i2c 12c90000.i2c: bus frequency set to 65 KHz
[    0.157929] s3c-i2c 12c90000.i2c: i2c-3: S3C I2C adapter
[    0.157941] driver: 's3c-i2c': driver_bound: bound to device '12c90000.i2c'
[    0.157953] bus: 'platform': really_probe: bound device 12c90000.i2c to driver s3c-i2c
[    0.157972] bus: 'platform': driver_probe_device: matched device 12ca0000.i2c with driver s3c-i2c
[    0.157988] bus: 'platform': really_probe: probing driver s3c-i2c with device 12ca0000.i2c
[    0.158063] s3c-i2c 12ca0000.i2c: slave address 0x00
[    0.158077] s3c-i2c 12ca0000.i2c: bus frequency set to 65 KHz
[    0.158230] s3c-i2c 12ca0000.i2c: i2c-4: S3C I2C adapter
[    0.158241] driver: 's3c-i2c': driver_bound: bound to device '12ca0000.i2c'
[    0.158253] bus: 'platform': really_probe: bound device 12ca0000.i2c to driver s3c-i2c
[    0.158272] bus: 'platform': driver_probe_device: matched device 12cb0000.i2c with driver s3c-i2c
[    0.158289] bus: 'platform': really_probe: probing driver s3c-i2c with device 12cb0000.i2c
[    0.158365] s3c-i2c 12cb0000.i2c: slave address 0x00
[    0.158379] s3c-i2c 12cb0000.i2c: bus frequency set to 65 KHz
[    0.158538] s3c-i2c 12cb0000.i2c: i2c-5: S3C I2C adapter
[    0.158550] driver: 's3c-i2c': driver_bound: bound to device '12cb0000.i2c'
[    0.158562] bus: 'platform': really_probe: bound device 12cb0000.i2c to driver s3c-i2c
[    0.158581] bus: 'platform': driver_probe_device: matched device 12cd0000.i2c with driver s3c-i2c
[    0.158598] bus: 'platform': really_probe: probing driver s3c-i2c with device 12cd0000.i2c
[    0.158676] s3c-i2c 12cd0000.i2c: slave address 0x00
[    0.158690] s3c-i2c 12cd0000.i2c: bus frequency set to 65 KHz
[    0.159023] s3c-i2c 12cd0000.i2c: i2c-7: S3C I2C adapter
[    0.159035] driver: 's3c-i2c': driver_bound: bound to device '12cd0000.i2c'
[    0.159046] bus: 'platform': really_probe: bound device 12cd0000.i2c to driver s3c-i2c
[    0.159066] bus: 'platform': driver_probe_device: matched device 12ce0000.i2c with driver s3c-i2c
[    0.159082] bus: 'platform': really_probe: probing driver s3c-i2c with device 12ce0000.i2c
[    0.159140] s3c-i2c 12ce0000.i2c: slave address 0x00
[    0.159153] s3c-i2c 12ce0000.i2c: bus frequency set to 378 KHz
[    0.159404] s3c-i2c 12ce0000.i2c: i2c-8: S3C I2C adapter
[    0.159416] driver: 's3c-i2c': driver_bound: bound to device '12ce0000.i2c'
[    0.159428] bus: 'platform': really_probe: bound device 12ce0000.i2c to driver s3c-i2c
[    0.159600] initcall i2c_adap_s3c_init+0x0/0x10 returned 0 after 24414 usecs
[    0.159617] calling  power_supply_class_init+0x0/0x50 @ 1
[    0.159665] initcall power_supply_class_init+0x0/0x50 returned 0 after 0 usecs
[    0.159684] calling  hwmon_init+0x0/0x34 @ 1
[    0.159728] initcall hwmon_init+0x0/0x34 returned 0 after 0 usecs
[    0.159743] calling  mmc_init+0x0/0x88 @ 1
[    0.159906] initcall mmc_init+0x0/0x88 returned 0 after 0 usecs
[    0.159921] calling  leds_init+0x0/0x4c @ 1
[    0.159966] initcall leds_init+0x0/0x4c returned 0 after 0 usecs
[    0.159983] calling  s2mps11_clk_init+0x0/0x10 @ 1
[    0.160082] initcall s2mps11_clk_init+0x0/0x10 returned 0 after 0 usecs
[    0.160099] calling  exynos3250_cmu_platform_init+0x0/0x18 @ 1
[    0.160321] initcall exynos3250_cmu_platform_init+0x0/0x18 returned -19 after 4882 usecs
[    0.160345] calling  iio_init+0x0/0x94 @ 1
[    0.160421] initcall iio_init+0x0/0x94 returned 0 after 0 usecs
[    0.160437] calling  init_soundcore+0x0/0x40 @ 1
[    0.160483] initcall init_soundcore+0x0/0x40 returned 0 after 0 usecs
[    0.160500] calling  alsa_sound_init+0x0/0xb0 @ 1
[    0.160527] Advanced Linux Sound Architecture Driver Initialized.
[    0.160540] initcall alsa_sound_init+0x0/0xb0 returned 0 after 0 usecs
[    0.160556] calling  proto_init+0x0/0xc @ 1
[    0.160573] initcall proto_init+0x0/0xc returned 0 after 0 usecs
[    0.160589] calling  net_dev_init+0x0/0x1e8 @ 1
[    0.161022] initcall net_dev_init+0x0/0x1e8 returned 0 after 0 usecs
[    0.161040] calling  neigh_init+0x0/0xa4 @ 1
[    0.161052] initcall neigh_init+0x0/0xa4 returned 0 after 0 usecs
[    0.161066] calling  genl_init+0x0/0x80 @ 1
[    0.161089] initcall genl_init+0x0/0x80 returned 0 after 0 usecs
[    0.161104] calling  cfg80211_init+0x0/0xe4 @ 1
[    0.161431] initcall cfg80211_init+0x0/0xe4 returned 0 after 0 usecs
[    0.161448] calling  watchdog_init+0x0/0xc0 @ 1
[    0.161497] initcall watchdog_init+0x0/0xc0 returned 0 after 0 usecs
[    0.161583] calling  proc_cpu_init+0x0/0x24 @ 1
[    0.161598] initcall proc_cpu_init+0x0/0x24 returned 0 after 0 usecs
[    0.161614] calling  dma_debug_do_init+0x0/0x8 @ 1
[    0.161625] initcall dma_debug_do_init+0x0/0x8 returned 0 after 0 usecs
[    0.161641] calling  alignment_init+0x0/0xe8 @ 1
[    0.161657] initcall alignment_init+0x0/0xe8 returned 0 after 0 usecs
[    0.161671] calling  clocksource_done_booting+0x0/0x44 @ 1
[    0.161708] clocksource: Switched to clocksource arch_sys_counter
[    0.161721] initcall clocksource_done_booting+0x0/0x44 returned 0 after 19 usecs
[    0.161742] calling  init_pipe_fs+0x0/0x58 @ 1
[    0.161776] initcall init_pipe_fs+0x0/0x58 returned 0 after 21 usecs
[    0.161792] calling  inotify_user_setup+0x0/0x54 @ 1
[    0.161808] initcall inotify_user_setup+0x0/0x54 returned 0 after 3 usecs
[    0.161823] calling  eventpoll_init+0x0/0xfc @ 1
[    0.161841] initcall eventpoll_init+0x0/0xfc returned 0 after 6 usecs
[    0.161857] calling  anon_inode_init+0x0/0x6c @ 1
[    0.161893] initcall anon_inode_init+0x0/0x6c returned 0 after 22 usecs
[    0.161910] calling  proc_cmdline_init+0x0/0x38 @ 1
[    0.161926] initcall proc_cmdline_init+0x0/0x38 returned 0 after 3 usecs
[    0.161942] calling  proc_consoles_init+0x0/0x38 @ 1
[    0.161957] initcall proc_consoles_init+0x0/0x38 returned 0 after 2 usecs
[    0.161973] calling  proc_cpuinfo_init+0x0/0x38 @ 1
[    0.161989] initcall proc_cpuinfo_init+0x0/0x38 returned 0 after 3 usecs
[    0.162005] calling  proc_devices_init+0x0/0x38 @ 1
[    0.162020] initcall proc_devices_init+0x0/0x38 returned 0 after 2 usecs
[    0.162036] calling  proc_interrupts_init+0x0/0x38 @ 1
[    0.162051] initcall proc_interrupts_init+0x0/0x38 returned 0 after 2 usecs
[    0.162067] calling  proc_loadavg_init+0x0/0x38 @ 1
[    0.162081] initcall proc_loadavg_init+0x0/0x38 returned 0 after 2 usecs
[    0.162097] calling  proc_meminfo_init+0x0/0x38 @ 1
[    0.162112] initcall proc_meminfo_init+0x0/0x38 returned 0 after 2 usecs
[    0.162128] calling  proc_stat_init+0x0/0x38 @ 1
[    0.162142] initcall proc_stat_init+0x0/0x38 returned 0 after 2 usecs
[    0.162158] calling  proc_uptime_init+0x0/0x38 @ 1
[    0.162173] initcall proc_uptime_init+0x0/0x38 returned 0 after 2 usecs
[    0.162189] calling  proc_version_init+0x0/0x38 @ 1
[    0.162204] initcall proc_version_init+0x0/0x38 returned 0 after 2 usecs
[    0.162220] calling  proc_softirqs_init+0x0/0x38 @ 1
[    0.162234] initcall proc_softirqs_init+0x0/0x38 returned 0 after 2 usecs
[    0.162250] calling  proc_kmsg_init+0x0/0x38 @ 1
[    0.162265] initcall proc_kmsg_init+0x0/0x38 returned 0 after 2 usecs
[    0.162280] calling  proc_page_init+0x0/0x58 @ 1
[    0.162297] initcall proc_page_init+0x0/0x58 returned 0 after 4 usecs
[    0.162313] calling  init_ramfs_fs+0x0/0x34 @ 1
[    0.162325] initcall init_ramfs_fs+0x0/0x34 returned 0 after 0 usecs
[    0.162339] calling  blk_scsi_ioctl_init+0x0/0xdc @ 1
[    0.162351] initcall blk_scsi_ioctl_init+0x0/0xdc returned 0 after 0 usecs
[    0.162365] calling  fb_console_init+0x0/0x140 @ 1
[    0.162476] initcall fb_console_init+0x0/0x140 returned 0 after 95 usecs
[    0.162493] calling  chr_dev_init+0x0/0xc8 @ 1
[    0.170806] initcall chr_dev_init+0x0/0xc8 returned 0 after 8100 usecs
[    0.170829] calling  firmware_class_init+0x0/0xc8 @ 1
[    0.170844] initcall firmware_class_init+0x0/0xc8 returned 0 after 2 usecs
[    0.170858] calling  thermal_init+0x0/0xb4 @ 1
[    0.171140] initcall thermal_init+0x0/0xb4 returned 0 after 262 usecs
[    0.171157] calling  cpufreq_gov_performance_init+0x0/0xc @ 1
[    0.171171] initcall cpufreq_gov_performance_init+0x0/0xc returned 0 after 1 usecs
[    0.171189] calling  cpufreq_gov_dbs_init+0x0/0xc @ 1
[    0.171202] initcall cpufreq_gov_dbs_init+0x0/0xc returned 0 after 0 usecs
[    0.171220] calling  sysctl_core_init+0x0/0x30 @ 1
[    0.171251] initcall sysctl_core_init+0x0/0x30 returned 0 after 17 usecs
[    0.171265] calling  eth_offload_init+0x0/0x18 @ 1
[    0.171276] initcall eth_offload_init+0x0/0x18 returned 0 after 0 usecs
[    0.171290] calling  inet_init+0x0/0x250 @ 1
[    0.171333] NET: Registered protocol family 2
[    0.171618] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    0.171673] TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
[    0.171813] TCP: Hash tables configured (established 8192 bind 8192)
[    0.171862] UDP hash table entries: 512 (order: 2, 24576 bytes)
[    0.171891] UDP-Lite hash table entries: 512 (order: 2, 24576 bytes)
[    0.171998] initcall inet_init+0x0/0x250 returned 0 after 677 usecs
[    0.172015] calling  ipv4_offload_init+0x0/0x68 @ 1
[    0.172027] initcall ipv4_offload_init+0x0/0x68 returned 0 after 0 usecs
[    0.172041] calling  af_unix_init+0x0/0x54 @ 1
[    0.172054] NET: Registered protocol family 1
[    0.172075] initcall af_unix_init+0x0/0x54 returned 0 after 21 usecs
[    0.172089] calling  ipv6_offload_init+0x0/0x88 @ 1
[    0.172103] initcall ipv6_offload_init+0x0/0x88 returned 0 after 1 usecs
[    0.172117] calling  init_sunrpc+0x0/0x6c @ 1
[    0.172265] RPC: Registered named UNIX socket transport module.
[    0.172278] RPC: Registered udp transport module.
[    0.172287] RPC: Registered tcp transport module.
[    0.172297] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.172310] initcall init_sunrpc+0x0/0x6c returned 0 after 175 usecs
[    0.172325] calling  populate_rootfs+0x0/0x25c @ 1
[    0.172448] initcall populate_rootfs+0x0/0x25c returned 0 after 106 usecs
[    0.172540] calling  bL_switcher_dummy_if_init+0x0/0xc @ 1
[    0.172686] initcall bL_switcher_dummy_if_init+0x0/0xc returned 0 after 128 usecs
[    0.172709] calling  proc_execdomains_init+0x0/0x38 @ 1
[    0.172727] initcall proc_execdomains_init+0x0/0x38 returned 0 after 4 usecs
[    0.172744] calling  ioresources_init+0x0/0x58 @ 1
[    0.172762] initcall ioresources_init+0x0/0x58 returned 0 after 5 usecs
[    0.172780] calling  init_sched_debug_procfs+0x0/0x3c @ 1
[    0.172796] initcall init_sched_debug_procfs+0x0/0x3c returned 0 after 3 usecs
[    0.172813] calling  irq_gc_init_ops+0x0/0x18 @ 1
[    0.172825] initcall irq_gc_init_ops+0x0/0x18 returned 0 after 1 usecs
[    0.172838] calling  irq_pm_init_ops+0x0/0x18 @ 1
[    0.172849] initcall irq_pm_init_ops+0x0/0x18 returned 0 after 0 usecs
[    0.172862] calling  init_posix_timers+0x0/0x210 @ 1
[    0.172882] initcall init_posix_timers+0x0/0x210 returned 0 after 8 usecs
[    0.172895] calling  init_posix_cpu_timers+0x0/0xdc @ 1
[    0.172907] initcall init_posix_cpu_timers+0x0/0xdc returned 0 after 0 usecs
[    0.172921] calling  timekeeping_init_ops+0x0/0x18 @ 1
[    0.172933] initcall timekeeping_init_ops+0x0/0x18 returned 0 after 0 usecs
[    0.172946] calling  init_clocksource_sysfs+0x0/0x74 @ 1
[    0.173133] initcall init_clocksource_sysfs+0x0/0x74 returned 0 after 169 usecs
[    0.173152] calling  init_timer_list_procfs+0x0/0x3c @ 1
[    0.173168] initcall init_timer_list_procfs+0x0/0x3c returned 0 after 3 usecs
[    0.173182] calling  alarmtimer_init+0x0/0x1a8 @ 1
[    0.173394] bus: 'platform': driver_probe_device: matched device alarmtimer with driver alarmtimer
[    0.173412] bus: 'platform': really_probe: probing driver alarmtimer with device alarmtimer
[    0.173453] alarmtimer: probe of alarmtimer rejects match -19
[    0.173471] initcall alarmtimer_init+0x0/0x1a8 returned 0 after 271 usecs
[    0.173486] calling  clockevents_init_sysfs+0x0/0xdc @ 1
[    0.173809] initcall clockevents_init_sysfs+0x0/0xdc returned 0 after 301 usecs
[    0.173828] calling  sched_clock_syscore_init+0x0/0x18 @ 1
[    0.173840] initcall sched_clock_syscore_init+0x0/0x18 returned 0 after 0 usecs
[    0.173857] calling  futex_init+0x0/0x108 @ 1
[    0.173870] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.173899] initcall futex_init+0x0/0x108 returned 0 after 29 usecs
[    0.173913] calling  proc_modules_init+0x0/0x38 @ 1
[    0.173929] initcall proc_modules_init+0x0/0x38 returned 0 after 4 usecs
[    0.173943] calling  kallsyms_init+0x0/0x38 @ 1
[    0.173957] initcall kallsyms_init+0x0/0x38 returned 0 after 3 usecs
[    0.173971] calling  pid_namespaces_init+0x0/0x40 @ 1
[    0.173987] initcall pid_namespaces_init+0x0/0x40 returned 0 after 4 usecs
[    0.174002] calling  utsname_sysctl_init+0x0/0x18 @ 1
[    0.174026] initcall utsname_sysctl_init+0x0/0x18 returned 0 after 12 usecs
[    0.174041] calling  init_per_zone_wmark_min+0x0/0xbc @ 1
[    0.174059] initcall init_per_zone_wmark_min+0x0/0xbc returned 0 after 5 usecs
[    0.174077] calling  kswapd_init+0x0/0x24 @ 1
[    0.174134] initcall kswapd_init+0x0/0x24 returned 0 after 43 usecs
[    0.174150] calling  extfrag_debug_init+0x0/0x94 @ 1
[    0.174181] initcall extfrag_debug_init+0x0/0x94 returned 0 after 17 usecs
[    0.174196] calling  setup_vmstat+0x0/0x1b4 @ 1
[    0.174219] initcall setup_vmstat+0x0/0x1b4 returned 0 after 12 usecs
[    0.174234] calling  mm_compute_batch_init+0x0/0x5c @ 1
[    0.174246] initcall mm_compute_batch_init+0x0/0x5c returned 0 after 0 usecs
[    0.174261] calling  slab_proc_init+0x0/0x38 @ 1
[    0.174275] initcall slab_proc_init+0x0/0x38 returned 0 after 2 usecs
[    0.174290] calling  workingset_init+0x0/0x50 @ 1
[    0.174302] initcall workingset_init+0x0/0x50 returned 0 after 1 usecs
[    0.174317] calling  proc_vmalloc_init+0x0/0x38 @ 1
[    0.174332] initcall proc_vmalloc_init+0x0/0x38 returned 0 after 3 usecs
[    0.174348] calling  memblock_init_debugfs+0x0/0x78 @ 1
[    0.174372] initcall memblock_init_debugfs+0x0/0x78 returned 0 after 11 usecs
[    0.174387] calling  procswaps_init+0x0/0x38 @ 1
[    0.174402] initcall procswaps_init+0x0/0x38 returned 0 after 2 usecs
[    0.174418] calling  slab_sysfs_init+0x0/0x11c @ 1
[    0.180816] initcall slab_sysfs_init+0x0/0x11c returned 0 after 6232 usecs
[    0.180838] calling  fcntl_init+0x0/0x40 @ 1
[    0.180858] initcall fcntl_init+0x0/0x40 returned 0 after 7 usecs
[    0.180874] calling  proc_filesystems_init+0x0/0x38 @ 1
[    0.180892] initcall proc_filesystems_init+0x0/0x38 returned 0 after 5 usecs
[    0.180909] calling  start_dirtytime_writeback+0x0/0x34 @ 1
[    0.180923] initcall start_dirtytime_writeback+0x0/0x34 returned 0 after 1 usecs
[    0.180942] calling  dio_init+0x0/0x40 @ 1
[    0.180961] initcall dio_init+0x0/0x40 returned 0 after 6 usecs
[    0.180977] calling  fsnotify_mark_init+0x0/0x40 @ 1
[    0.181031] initcall fsnotify_mark_init+0x0/0x40 returned 0 after 39 usecs
[    0.181049] calling  dnotify_init+0x0/0x84 @ 1
[    0.181074] initcall dnotify_init+0x0/0x84 returned 0 after 12 usecs
[    0.181089] calling  aio_setup+0x0/0x88 @ 1
[    0.181137] initcall aio_setup+0x0/0x88 returned 0 after 34 usecs
[    0.181154] calling  proc_locks_init+0x0/0x38 @ 1
[    0.181170] initcall proc_locks_init+0x0/0x38 returned 0 after 3 usecs
[    0.181186] calling  init_mbcache+0x0/0x18 @ 1
[    0.181198] initcall init_mbcache+0x0/0x18 returned 0 after 0 usecs
[    0.181213] calling  init_grace+0x0/0xc @ 1
[    0.181227] initcall init_grace+0x0/0xc returned 0 after 2 usecs
[    0.181242] calling  init_devpts_fs+0x0/0x70 @ 1
[    0.181281] initcall init_devpts_fs+0x0/0x70 returned 0 after 25 usecs
[    0.181298] calling  init_ext2_fs+0x0/0x78 @ 1
[    0.181444] initcall init_ext2_fs+0x0/0x78 returned 0 after 128 usecs
[    0.181462] calling  ext4_init_fs+0x0/0x1ac @ 1
[    0.182207] initcall ext4_init_fs+0x0/0x1ac returned 0 after 714 usecs
[    0.182226] calling  journal_init+0x0/0x118 @ 1
[    0.182652] initcall journal_init+0x0/0x118 returned 0 after 401 usecs
[    0.182670] calling  init_cramfs_fs+0x0/0x38 @ 1
[    0.182700] initcall init_cramfs_fs+0x0/0x38 returned 0 after 16 usecs
[    0.182717] calling  init_fat_fs+0x0/0x64 @ 1
[    0.182984] initcall init_fat_fs+0x0/0x64 returned 0 after 247 usecs
[    0.183003] calling  init_vfat_fs+0x0/0xc @ 1
[    0.183017] initcall init_vfat_fs+0x0/0xc returned 0 after 1 usecs
[    0.183033] calling  init_msdos_fs+0x0/0xc @ 1
[    0.183046] initcall init_msdos_fs+0x0/0xc returned 0 after 1 usecs
[    0.183062] calling  init_nfs_fs+0x0/0x160 @ 1
[    0.183598] initcall init_nfs_fs+0x0/0x160 returned 0 after 509 usecs
[    0.183613] calling  init_nfs_v2+0x0/0x18 @ 1
[    0.183625] initcall init_nfs_v2+0x0/0x18 returned 0 after 0 usecs
[    0.183638] calling  init_nfs_v3+0x0/0x18 @ 1
[    0.183649] initcall init_nfs_v3+0x0/0x18 returned 0 after 0 usecs
[    0.183662] calling  init_nlm+0x0/0x70 @ 1
[    0.183686] initcall init_nlm+0x0/0x70 returned 0 after 12 usecs
[    0.183699] calling  init_nls_cp437+0x0/0x10 @ 1
[    0.183711] initcall init_nls_cp437+0x0/0x10 returned 0 after 0 usecs
[    0.183724] calling  init_nls_ascii+0x0/0x10 @ 1
[    0.183735] initcall init_nls_ascii+0x0/0x10 returned 0 after 0 usecs
[    0.183748] calling  init_nls_iso8859_1+0x0/0x10 @ 1
[    0.183759] initcall init_nls_iso8859_1+0x0/0x10 returned 0 after 0 usecs
[    0.183772] calling  init_romfs_fs+0x0/0x98 @ 1
[    0.183781] romfs: ROMFS MTD (C) 2007 Red Hat, Inc.
[    0.183926] initcall init_romfs_fs+0x0/0x98 returned 0 after 138 usecs
[    0.183941] calling  ipc_init+0x0/0x18 @ 1
[    0.183961] initcall ipc_init+0x0/0x18 returned 0 after 9 usecs
[    0.183974] calling  ipc_sysctl_init+0x0/0x18 @ 1
[    0.183996] initcall ipc_sysctl_init+0x0/0x18 returned 0 after 10 usecs
[    0.184010] calling  crypto_algapi_init+0x0/0x10 @ 1
[    0.184024] initcall crypto_algapi_init+0x0/0x10 returned 0 after 3 usecs
[    0.184038] calling  chainiv_module_init+0x0/0xc @ 1
[    0.184051] initcall chainiv_module_init+0x0/0xc returned 0 after 2 usecs
[    0.184065] calling  eseqiv_module_init+0x0/0xc @ 1
[    0.184076] initcall eseqiv_module_init+0x0/0xc returned 0 after 0 usecs
[    0.184089] calling  crypto_null_mod_init+0x0/0x4c @ 1
[    0.184291] initcall crypto_null_mod_init+0x0/0x4c returned 0 after 184 usecs
[    0.184307] calling  sha256_generic_mod_init+0x0/0x10 @ 1
[    0.184402] initcall sha256_generic_mod_init+0x0/0x10 returned 0 after 79 usecs
[    0.184421] calling  crypto_cbc_module_init+0x0/0xc @ 1
[    0.184433] initcall crypto_cbc_module_init+0x0/0xc returned 0 after 0 usecs
[    0.184446] calling  aes_init+0x0/0xc @ 1
[    0.184503] initcall aes_init+0x0/0xc returned 0 after 43 usecs
[    0.184517] calling  crc32c_mod_init+0x0/0xc @ 1
[    0.184574] initcall crc32c_mod_init+0x0/0xc returned 0 after 43 usecs
[    0.184588] calling  proc_genhd_init+0x0/0x58 @ 1
[    0.184606] initcall proc_genhd_init+0x0/0x58 returned 0 after 6 usecs
[    0.184621] calling  init_emergency_pool+0x0/0x78 @ 1
[    0.184654] bounce: pool size: 64 pages
[    0.184665] initcall init_emergency_pool+0x0/0x78 returned 0 after 32 usecs
[    0.184679] calling  noop_init+0x0/0xc @ 1
[    0.184690] io scheduler noop registered
[    0.184701] initcall noop_init+0x0/0xc returned 0 after 10 usecs
[    0.184714] calling  deadline_init+0x0/0xc @ 1
[    0.184724] io scheduler deadline registered
[    0.184735] initcall deadline_init+0x0/0xc returned 0 after 9 usecs
[    0.184748] calling  cfq_init+0x0/0xa4 @ 1
[    0.184908] io scheduler cfq registered (default)
[    0.184922] initcall cfq_init+0x0/0xa4 returned 0 after 157 usecs
[    0.184936] calling  percpu_counter_startup+0x0/0x1c @ 1
[    0.184950] initcall percpu_counter_startup+0x0/0x1c returned 0 after 2 usecs
[    0.184965] calling  phy_core_init+0x0/0x58 @ 1
[    0.185013] initcall phy_core_init+0x0/0x58 returned 0 after 35 usecs
[    0.185030] calling  exynos_dp_video_phy_driver_init+0x0/0x10 @ 1
[    0.185148] bus: 'platform': driver_probe_device: matched device video-phy@10040720 with driver exynos-dp-video-phy
[    0.185167] bus: 'platform': really_probe: probing driver exynos-dp-video-phy with device video-phy@10040720
[    0.185389] driver: 'exynos-dp-video-phy': driver_bound: bound to device 'video-phy@10040720'
[    0.185409] bus: 'platform': really_probe: bound device video-phy@10040720 to driver exynos-dp-video-phy
[    0.185524] initcall exynos_dp_video_phy_driver_init+0x0/0x10 returned 0 after 468 usecs
[    0.185546] calling  exynos_mipi_video_phy_driver_init+0x0/0x10 @ 1
[    0.185682] initcall exynos_mipi_video_phy_driver_init+0x0/0x10 returned 0 after 119 usecs
[    0.185702] calling  exynos_sata_phy_driver_init+0x0/0x10 @ 1
[    0.185835] initcall exynos_sata_phy_driver_init+0x0/0x10 returned 0 after 115 usecs
[    0.185856] calling  samsung_usb2_phy_driver_init+0x0/0x10 @ 1
[    0.185943] bus: 'platform': driver_probe_device: matched device 12130000.phy with driver samsung-usb2-phy
[    0.185961] bus: 'platform': really_probe: probing driver samsung-usb2-phy with device 12130000.phy
[    0.186427] driver: 'samsung-usb2-phy': driver_bound: bound to device '12130000.phy'
[    0.186444] bus: 'platform': really_probe: bound device 12130000.phy to driver samsung-usb2-phy
[    0.186562] initcall samsung_usb2_phy_driver_init+0x0/0x10 returned 0 after 675 usecs
[    0.186582] calling  exynos5_usb3drd_phy_init+0x0/0x10 @ 1
[    0.186667] bus: 'platform': driver_probe_device: matched device 12100000.phy with driver exynos5_usb3drd_phy
[    0.186684] bus: 'platform': really_probe: probing driver exynos5_usb3drd_phy with device 12100000.phy
[    0.186848] 12100000.phy supply vbus-boost not found, using dummy regulator
[    0.187098] driver: 'exynos5_usb3drd_phy': driver_bound: bound to device '12100000.phy'
[    0.187116] bus: 'platform': really_probe: bound device 12100000.phy to driver exynos5_usb3drd_phy
[    0.187243] initcall exynos5_usb3drd_phy_init+0x0/0x10 returned 0 after 631 usecs
[    0.187264] calling  pwm_samsung_driver_init+0x0/0x10 @ 1
[    0.187360] bus: 'platform': driver_probe_device: matched device 12dd0000.pwm with driver samsung-pwm
[    0.187377] bus: 'platform': really_probe: probing driver samsung-pwm with device 12dd0000.pwm
[    0.187536] driver: 'samsung-pwm': driver_bound: bound to device '12dd0000.pwm'
[    0.187554] bus: 'platform': really_probe: bound device 12dd0000.pwm to driver samsung-pwm
[    0.187674] initcall pwm_samsung_driver_init+0x0/0x10 returned 0 after 386 usecs
[    0.187693] calling  platform_lcd_driver_init+0x0/0x10 @ 1
[    0.187816] initcall platform_lcd_driver_init+0x0/0x10 returned 0 after 106 usecs
[    0.187836] calling  genericbl_driver_init+0x0/0x10 @ 1
[    0.187926] initcall genericbl_driver_init+0x0/0x10 returned 0 after 74 usecs
[    0.187943] calling  pwm_backlight_driver_init+0x0/0x10 @ 1
[    0.188023] bus: 'platform': driver_probe_device: matched device backlight with driver pwm-backlight
[    0.188040] bus: 'platform': really_probe: probing driver pwm-backlight with device backlight
[    0.188109] pwm-backlight backlight: GPIO lookup for consumer enable
[    0.188121] pwm-backlight backlight: using device tree for GPIO lookup
[    0.188140] of_get_named_gpiod_flags: parsed 'enable-gpios' property of node '/backlight[0]' - status (0)
[    0.188208] platform backlight: Driver pwm-backlight requests probe deferral
[    0.188221] platform backlight: Added to deferred list
[    0.188283] initcall pwm_backlight_driver_init+0x0/0x10 returned 0 after 318 usecs
[    0.188304] calling  exynos_mipi_dsi_driver_init+0x0/0x10 @ 1
[    0.188393] initcall exynos_mipi_dsi_driver_init+0x0/0x10 returned 0 after 73 usecs
[    0.188413] calling  pl330_driver_init+0x0/0xc @ 1
[    0.188432] bus: 'amba': driver_probe_device: matched device 121a0000.pdma with driver dma-pl330
[    0.188449] bus: 'amba': really_probe: probing driver dma-pl330 with device 121a0000.pdma
[    0.191215] dma-pl330 121a0000.pdma: Loaded driver for PL330 DMAC-241330
[    0.191232] dma-pl330 121a0000.pdma: 	DBUFF-32x4bytes Num_Chans-8 Num_Peri-32 Num_Events-32
[    0.191253] driver: 'dma-pl330': driver_bound: bound to device '121a0000.pdma'
[    0.191269] bus: 'amba': really_probe: bound device 121a0000.pdma to driver dma-pl330
[    0.191298] bus: 'amba': driver_probe_device: matched device 121b0000.pdma with driver dma-pl330
[    0.191315] bus: 'amba': really_probe: probing driver dma-pl330 with device 121b0000.pdma
[    0.194244] dma-pl330 121b0000.pdma: Loaded driver for PL330 DMAC-241330
[    0.194262] dma-pl330 121b0000.pdma: 	DBUFF-32x4bytes Num_Chans-8 Num_Peri-32 Num_Events-32
[    0.194282] driver: 'dma-pl330': driver_bound: bound to device '121b0000.pdma'
[    0.194298] bus: 'amba': really_probe: bound device 121b0000.pdma to driver dma-pl330
[    0.194327] bus: 'amba': driver_probe_device: matched device 10800000.mdma with driver dma-pl330
[    0.194344] bus: 'amba': really_probe: probing driver dma-pl330 with device 10800000.mdma
[    0.195148] dma-pl330 10800000.mdma: Loaded driver for PL330 DMAC-241330
[    0.195164] dma-pl330 10800000.mdma: 	DBUFF-64x8bytes Num_Chans-8 Num_Peri-1 Num_Events-32
[    0.195183] driver: 'dma-pl330': driver_bound: bound to device '10800000.mdma'
[    0.195198] bus: 'amba': really_probe: bound device 10800000.mdma to driver dma-pl330
[    0.195225] bus: 'amba': driver_probe_device: matched device 11c10000.mdma with driver dma-pl330
[    0.195241] bus: 'amba': really_probe: probing driver dma-pl330 with device 11c10000.mdma
[    0.196010] dma-pl330 11c10000.mdma: Loaded driver for PL330 DMAC-241330
[    0.196024] dma-pl330 11c10000.mdma: 	DBUFF-64x8bytes Num_Chans-8 Num_Peri-1 Num_Events-32
[    0.196042] driver: 'dma-pl330': driver_bound: bound to device '11c10000.mdma'
[    0.196057] bus: 'amba': really_probe: bound device 11c10000.mdma to driver dma-pl330
[    0.196127] initcall pl330_driver_init+0x0/0xc returned 0 after 7517 usecs
[    0.196144] calling  max77802_pmic_driver_init+0x0/0x10 @ 1
[    0.196257] initcall max77802_pmic_driver_init+0x0/0x10 returned 0 after 96 usecs
[    0.196278] calling  s2mpa01_pmic_driver_init+0x0/0x10 @ 1
[    0.196366] initcall s2mpa01_pmic_driver_init+0x0/0x10 returned 0 after 72 usecs
[    0.196385] calling  pty_init+0x0/0x3dc @ 1
[    0.249310] initcall pty_init+0x0/0x3dc returned 0 after 51665 usecs
[    0.249336] calling  sysrq_init+0x0/0xa0 @ 1
[    0.249359] initcall sysrq_init+0x0/0xa0 returned 0 after 9 usecs
[    0.249376] calling  serial8250_init+0x0/0x144 @ 1
[    0.249387] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.250295] bus: 'platform': driver_probe_device: matched device serial8250 with driver serial8250
[    0.250315] bus: 'platform': really_probe: probing driver serial8250 with device serial8250
[    0.250352] driver: 'serial8250': driver_bound: bound to device 'serial8250'
[    0.250365] bus: 'platform': really_probe: bound device serial8250 to driver serial8250
[    0.250428] initcall serial8250_init+0x0/0x144 returned 0 after 1012 usecs
[    0.250446] calling  samsung_serial_driver_init+0x0/0x10 @ 1
[    0.250478] bus: 'platform': driver_probe_device: matched device 12c00000.serial with driver samsung-uart
[    0.250496] bus: 'platform': really_probe: probing driver samsung-uart with device 12c00000.serial
[    0.250603] 12c00000.serial: ttySAC0 at MMIO 0x12c00000 (irq = 56, base_baud = 0) is a S3C6400/10
[    0.250823] driver: 'samsung-uart': driver_bound: bound to device '12c00000.serial'
[    0.250840] bus: 'platform': really_probe: bound device 12c00000.serial to driver samsung-uart
[    0.250861] bus: 'platform': driver_probe_device: matched device 12c10000.serial with driver samsung-uart
[    0.250879] bus: 'platform': really_probe: probing driver samsung-uart with device 12c10000.serial
[    0.250943] 12c10000.serial: ttySAC1 at MMIO 0x12c10000 (irq = 57, base_baud = 0) is a S3C6400/10
[    0.251144] driver: 'samsung-uart': driver_bound: bound to device '12c10000.serial'
[    0.251161] bus: 'platform': really_probe: bound device 12c10000.serial to driver samsung-uart
[    0.251181] bus: 'platform': driver_probe_device: matched device 12c20000.serial with driver samsung-uart
[    0.251198] bus: 'platform': really_probe: probing driver samsung-uart with device 12c20000.serial
[    0.251264] 12c20000.serial: ttySAC2 at MMIO 0x12c20000 (irq = 58, base_baud = 0) is a S3C6400/10
[    0.251468] driver: 'samsung-uart': driver_bound: bound to device '12c20000.serial'
[    0.251484] bus: 'platform': really_probe: bound device 12c20000.serial to driver samsung-uart
[    0.251505] bus: 'platform': driver_probe_device: matched device 12c30000.serial with driver samsung-uart
[    0.251522] bus: 'platform': really_probe: probing driver samsung-uart with device 12c30000.serial
[    0.251585] 12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 59, base_baud = 0) is a S3C6400/10
[    0.251852] driver: 'samsung-uart': driver_bound: bound to device '12c30000.serial'
[    0.251870] bus: 'platform': really_probe: bound device 12c30000.serial to driver samsung-uart
[    0.252163] initcall samsung_serial_driver_init+0x0/0x10 returned 0 after 1660 usecs
[    0.252185] calling  of_platform_serial_driver_init+0x0/0x10 @ 1
[    0.252481] initcall of_platform_serial_driver_init+0x0/0x10 returned 0 after 273 usecs
[    0.252502] calling  hwrng_modinit+0x0/0xc @ 1
[    0.252635] initcall hwrng_modinit+0x0/0xc returned 0 after 116 usecs
[    0.252652] calling  exynos_rng_driver_init+0x0/0x10 @ 1
[    0.252744] initcall exynos_rng_driver_init+0x0/0x10 returned 0 after 76 usecs
[    0.252765] calling  rng_init+0x0/0xc @ 1
[    0.252780] initcall rng_init+0x0/0xc returned 0 after 3 usecs
[    0.252795] calling  tpm_tis_i2c_driver_init+0x0/0x10 @ 1
[    0.252884] initcall tpm_tis_i2c_driver_init+0x0/0x10 returned 0 after 72 usecs
[    0.252904] calling  drm_core_init+0x0/0x104 @ 1
[    0.252967] [drm] Initialized drm 1.1.0 20060810
[    0.252981] initcall drm_core_init+0x0/0x104 returned 0 after 63 usecs
[    0.252996] calling  exynos_drm_init+0x0/0xc0 @ 1
[    0.253134] bus: 'platform': driver_probe_device: matched device 14400000.fimd with driver exynos4-fb
[    0.253152] bus: 'platform': really_probe: probing driver exynos4-fb with device 14400000.fimd
[    0.253290] driver: 'exynos4-fb': driver_bound: bound to device '14400000.fimd'
[    0.253307] bus: 'platform': really_probe: bound device 14400000.fimd to driver exynos4-fb
[    0.253551] bus: 'platform': driver_probe_device: matched device 145b0000.dp-controller with driver exynos-dp
[    0.253570] bus: 'platform': really_probe: probing driver exynos-dp with device 145b0000.dp-controller
[    0.254151] platform 145b0000.dp-controller: Driver exynos-dp requests probe deferral
[    0.254168] platform 145b0000.dp-controller: Added to deferred list
[    0.254605] bus: 'platform': driver_probe_device: matched device 14450000.mixer with driver exynos-mixer
[    0.254623] bus: 'platform': really_probe: probing driver exynos-mixer with device 14450000.mixer
[    0.255125] driver: 'exynos-mixer': driver_bound: bound to device '14450000.mixer'
[    0.255142] bus: 'platform': really_probe: bound device 14450000.mixer to driver exynos-mixer
[    0.255358] bus: 'platform': driver_probe_device: matched device 14530000.hdmi with driver exynos-hdmi
[    0.255376] bus: 'platform': really_probe: probing driver exynos-hdmi with device 14530000.hdmi
[    0.255911] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of node '/hdmi[0]' - status (0)
[    0.256608] [drm:hdmi_probe] *ERROR* failed to get hdmi-en regulator
[    0.256623] [drm:hdmi_probe] *ERROR* hdmi_resources_init failed
[    0.256796] platform 14530000.hdmi: Driver exynos-hdmi requests probe deferral
[    0.256813] platform 14530000.hdmi: Added to deferred list
[    0.256978] bus: 'platform': driver_probe_device: matched device exynos-drm with driver exynos-drm
[    0.256996] bus: 'platform': really_probe: probing driver exynos-drm with device exynos-drm
[    0.257649] driver: 'exynos-drm': driver_bound: bound to device 'exynos-drm'
[    0.257661] bus: 'platform': really_probe: bound device exynos-drm to driver exynos-drm
[    0.257723] initcall exynos_drm_init+0x0/0xc0 returned 0 after 4604 usecs
[    0.257742] calling  panel_simple_init+0x0/0x34 @ 1
[    0.258146] bus: 'platform': driver_probe_device: matched device panel with driver panel-simple
[    0.258162] bus: 'platform': really_probe: probing driver panel-simple with device panel
[    0.258232] platform panel: Driver panel-simple requests probe deferral
[    0.258244] platform panel: Added to deferred list
[    0.258358] initcall panel_simple_init+0x0/0x34 returned 0 after 586 usecs
[    0.258376] calling  s6e8aa0_driver_init+0x0/0x10 @ 1
[    0.258433] initcall s6e8aa0_driver_init+0x0/0x10 returned 0 after 42 usecs
[    0.258450] calling  ptn3460_driver_init+0x0/0x10 @ 1
[    0.258476] bus: 'i2c': driver_probe_device: matched device 7-0020 with driver nxp,ptn3460
[    0.258497] bus: 'i2c': really_probe: probing driver nxp,ptn3460 with device 7-0020
[    0.258554] i2c 7-0020: Driver nxp,ptn3460 requests probe deferral
[    0.258566] i2c 7-0020: Added to deferred list
[    0.258641] initcall ptn3460_driver_init+0x0/0x10 returned 0 after 173 usecs
[    0.258659] calling  ps8622_driver_init+0x0/0x10 @ 1
[    0.258732] initcall ps8622_driver_init+0x0/0x10 returned 0 after 58 usecs
[    0.258751] calling  topology_sysfs_init+0x0/0x7c @ 1
[    0.258812] initcall topology_sysfs_init+0x0/0x7c returned 0 after 47 usecs
[    0.258828] calling  cacheinfo_sysfs_init+0x0/0x94 @ 1
[    0.258841] initcall cacheinfo_sysfs_init+0x0/0x94 returned -2 after 1 usecs
[    0.258857] calling  devcoredump_init+0x0/0x14 @ 1
[    0.258911] initcall devcoredump_init+0x0/0x14 returned 0 after 39 usecs
[    0.258928] calling  brd_init+0x0/0x170 @ 1
[    0.266174] brd: module loaded
[    0.266198] initcall brd_init+0x0/0x170 returned 0 after 7083 usecs
[    0.266215] calling  loop_init+0x0/0x12c @ 1
[    0.270220] loop: module loaded
[    0.270243] initcall loop_init+0x0/0x12c returned 0 after 3917 usecs
[    0.270261] calling  init_cryptoloop+0x0/0x2c @ 1
[    0.270274] initcall init_cryptoloop+0x0/0x2c returned 0 after 0 usecs
[    0.270290] calling  cros_ec_driver_init+0x0/0x10 @ 1
[    0.270378] initcall cros_ec_driver_init+0x0/0x10 returned 0 after 72 usecs
[    0.270396] calling  cros_ec_driver_spi_init+0x0/0xc @ 1
[    0.270455] initcall cros_ec_driver_spi_init+0x0/0xc returned 0 after 43 usecs
[    0.270475] calling  init_sd+0x0/0x164 @ 1
[    0.270603] initcall init_sd+0x0/0x164 returned 0 after 111 usecs
[    0.270620] calling  init_sg+0x0/0x134 @ 1
[    0.270697] initcall init_sg+0x0/0x134 returned 0 after 61 usecs
[    0.270714] calling  s3c64xx_spi_driver_init+0x0/0x10 @ 1
[    0.270835] bus: 'platform': driver_probe_device: matched device 12d30000.spi with driver s3c64xx-spi
[    0.270853] bus: 'platform': really_probe: probing driver s3c64xx-spi with device 12d30000.spi
[    0.271044] of_get_named_gpiod_flags: parsed 'cs-gpios' property of node '/spi@12d30000[0]' - status (0)
[    0.271294] driver: 's3c64xx-spi': driver_bound: bound to device '12d30000.spi'
[    0.271312] bus: 'platform': really_probe: bound device 12d30000.spi to driver s3c64xx-spi
[    0.271506] initcall s3c64xx_spi_driver_init+0x0/0x10 returned 0 after 758 usecs
[    0.271529] calling  net_olddevs_init+0x0/0x6c @ 1
[    0.271546] initcall net_olddevs_init+0x0/0x6c returned 0 after 4 usecs
[    0.271562] calling  smsc911x_init_module+0x0/0x10 @ 1
[    0.271697] initcall smsc911x_init_module+0x0/0x10 returned 0 after 118 usecs
[    0.271770] calling  rtl8152_driver_init+0x0/0x18 @ 1
[    0.271867] usbcore: registered new interface driver r8152
[    0.271883] initcall rtl8152_driver_init+0x0/0x18 returned 0 after 96 usecs
[    0.271900] calling  asix_driver_init+0x0/0x18 @ 1
[    0.271987] usbcore: registered new interface driver asix
[    0.272002] initcall asix_driver_init+0x0/0x18 returned 0 after 86 usecs
[    0.272019] calling  ax88179_178a_driver_init+0x0/0x18 @ 1
[    0.272086] usbcore: registered new interface driver ax88179_178a
[    0.272102] initcall ax88179_178a_driver_init+0x0/0x18 returned 0 after 67 usecs
[    0.272122] calling  cdc_driver_init+0x0/0x18 @ 1
[    0.272192] usbcore: registered new interface driver cdc_ether
[    0.272207] initcall cdc_driver_init+0x0/0x18 returned 0 after 69 usecs
[    0.272223] calling  smsc75xx_driver_init+0x0/0x18 @ 1
[    0.272305] usbcore: registered new interface driver smsc75xx
[    0.272321] initcall smsc75xx_driver_init+0x0/0x18 returned 0 after 82 usecs
[    0.272338] calling  smsc95xx_driver_init+0x0/0x18 @ 1
[    0.272415] usbcore: registered new interface driver smsc95xx
[    0.272430] initcall smsc95xx_driver_init+0x0/0x18 returned 0 after 76 usecs
[    0.272447] calling  net1080_driver_init+0x0/0x18 @ 1
[    0.272510] usbcore: registered new interface driver net1080
[    0.272525] initcall net1080_driver_init+0x0/0x18 returned 0 after 63 usecs
[    0.272541] calling  cdc_subset_driver_init+0x0/0x18 @ 1
[    0.272602] usbcore: registered new interface driver cdc_subset
[    0.272617] initcall cdc_subset_driver_init+0x0/0x18 returned 0 after 61 usecs
[    0.272637] calling  zaurus_driver_init+0x0/0x18 @ 1
[    0.272697] usbcore: registered new interface driver zaurus
[    0.272712] initcall zaurus_driver_init+0x0/0x18 returned 0 after 60 usecs
[    0.272728] calling  usbnet_init+0x0/0x30 @ 1
[    0.272747] initcall usbnet_init+0x0/0x30 returned 0 after 6 usecs
[    0.272763] calling  cdc_ncm_driver_init+0x0/0x18 @ 1
[    0.272837] usbcore: registered new interface driver cdc_ncm
[    0.272852] initcall cdc_ncm_driver_init+0x0/0x18 returned 0 after 73 usecs
[    0.272868] calling  dwc3_driver_init+0x0/0x10 @ 1
[    0.273026] initcall dwc3_driver_init+0x0/0x10 returned 0 after 140 usecs
[    0.273044] calling  dwc3_exynos_driver_init+0x0/0x10 @ 1
[    0.273110] bus: 'platform': driver_probe_device: matched device usb@12000000 with driver exynos-dwc3
[    0.273127] bus: 'platform': really_probe: probing driver exynos-dwc3 with device usb@12000000
[    0.273407] exynos-dwc3 usb@12000000: no suspend clk specified
[    0.273446] usb@12000000 supply vdd33 not found, using dummy regulator
[    0.273499] usb@12000000 supply vdd10 not found, using dummy regulator
[    0.273738] bus: 'platform': driver_probe_device: matched device 12000000.dwc3 with driver dwc3
[    0.273756] bus: 'platform': really_probe: probing driver dwc3 with device 12000000.dwc3
[    0.474148] driver: 'dwc3': driver_bound: bound to device '12000000.dwc3'
[    0.474163] bus: 'platform': really_probe: bound device 12000000.dwc3 to driver dwc3
[    0.474182] driver: 'exynos-dwc3': driver_bound: bound to device 'usb@12000000'
[    0.474198] bus: 'platform': really_probe: bound device usb@12000000 to driver exynos-dwc3
[    0.474322] initcall dwc3_exynos_driver_init+0x0/0x10 returned 0 after 196544 usecs
[    0.474345] calling  dwc2_platform_driver_init+0x0/0x10 @ 1
[    0.474531] initcall dwc2_platform_driver_init+0x0/0x10 returned 0 after 167 usecs
[    0.474554] calling  xhci_plat_init+0x0/0x2c @ 1
[    0.474694] bus: 'platform': driver_probe_device: matched device xhci-hcd.2.auto with driver xhci-hcd
[    0.474712] bus: 'platform': really_probe: probing driver xhci-hcd with device xhci-hcd.2.auto
[    0.474759] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[    0.474785] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 1
[    0.475001] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[    0.475044] xhci-hcd xhci-hcd.2.auto: irq 144, io mem 0x12000000
[    0.475153] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    0.475166] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.475182] usb usb1: Product: xHCI Host Controller
[    0.475192] usb usb1: Manufacturer: Linux 4.3.0-rc5-next-20151013-dirty xhci-hcd
[    0.475207] usb usb1: SerialNumber: xhci-hcd.2.auto
[    0.475534] bus: 'usb': driver_probe_device: matched device usb1 with driver usb
[    0.475551] bus: 'usb': really_probe: probing driver usb with device usb1
[    0.475689] bus: 'usb': driver_probe_device: matched device 1-0:1.0 with driver hub
[    0.475706] bus: 'usb': really_probe: probing driver hub with device 1-0:1.0
[    0.475736] hub 1-0:1.0: USB hub found
[    0.475764] hub 1-0:1.0: 1 port detected
[    0.475881] driver: 'hub': driver_bound: bound to device '1-0:1.0'
[    0.475895] bus: 'usb': really_probe: bound device 1-0:1.0 to driver hub
[    0.475967] driver: 'usb': driver_bound: bound to device 'usb1'
[    0.475979] bus: 'usb': really_probe: bound device usb1 to driver usb
[    0.476058] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[    0.476077] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 2
[    0.476132] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[    0.476211] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[    0.476224] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.476239] usb usb2: Product: xHCI Host Controller
[    0.476250] usb usb2: Manufacturer: Linux 4.3.0-rc5-next-20151013-dirty xhci-hcd
[    0.476265] usb usb2: SerialNumber: xhci-hcd.2.auto
[    0.476551] bus: 'usb': driver_probe_device: matched device usb2 with driver usb
[    0.476568] bus: 'usb': really_probe: probing driver usb with device usb2
[    0.476739] bus: 'usb': driver_probe_device: matched device 2-0:1.0 with driver hub
[    0.476757] bus: 'usb': really_probe: probing driver hub with device 2-0:1.0
[    0.476786] hub 2-0:1.0: USB hub found
[    0.476811] hub 2-0:1.0: 1 port detected
[    0.476926] driver: 'hub': driver_bound: bound to device '2-0:1.0'
[    0.476938] bus: 'usb': really_probe: bound device 2-0:1.0 to driver hub
[    0.477007] driver: 'usb': driver_bound: bound to device 'usb2'
[    0.477019] bus: 'usb': really_probe: bound device usb2 to driver usb
[    0.477098] driver: 'xhci-hcd': driver_bound: bound to device 'xhci-hcd.2.auto'
[    0.477114] bus: 'platform': really_probe: bound device xhci-hcd.2.auto to driver xhci-hcd
[    0.477176] initcall xhci_plat_init+0x0/0x2c returned 0 after 2546 usecs
[    0.477194] calling  ehci_hcd_init+0x0/0x70 @ 1
[    0.477204] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.477217] initcall ehci_hcd_init+0x0/0x70 returned 0 after 10 usecs
[    0.477233] calling  ehci_exynos_init+0x0/0x54 @ 1
[    0.477243] ehci-exynos: EHCI EXYNOS driver
[    0.477322] bus: 'platform': driver_probe_device: matched device 12110000.usb with driver exynos-ehci
[    0.477340] bus: 'platform': really_probe: probing driver exynos-ehci with device 12110000.usb
[    0.477387] of_get_named_gpiod_flags: parsed 'samsung,vbus-gpio' property of node '/usb@12110000[0]' - status (0)
[    0.477587] exynos-ehci 12110000.usb: EHCI Host Controller
[    0.477613] exynos-ehci 12110000.usb: new USB bus registered, assigned bus number 3
[    0.477724] exynos-ehci 12110000.usb: irq 108, io mem 0x12110000
[    0.486728] exynos-ehci 12110000.usb: USB 2.0 started, EHCI 1.00
[    0.486832] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[    0.486846] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.486861] usb usb3: Product: EHCI Host Controller
[    0.486871] usb usb3: Manufacturer: Linux 4.3.0-rc5-next-20151013-dirty ehci_hcd
[    0.486886] usb usb3: SerialNumber: 12110000.usb
[    0.487180] bus: 'usb': driver_probe_device: matched device usb3 with driver usb
[    0.487197] bus: 'usb': really_probe: probing driver usb with device usb3
[    0.487328] bus: 'usb': driver_probe_device: matched device 3-0:1.0 with driver hub
[    0.487345] bus: 'usb': really_probe: probing driver hub with device 3-0:1.0
[    0.487374] hub 3-0:1.0: USB hub found
[    0.487398] hub 3-0:1.0: 3 ports detected
[    0.487630] driver: 'hub': driver_bound: bound to device '3-0:1.0'
[    0.487643] bus: 'usb': really_probe: bound device 3-0:1.0 to driver hub
[    0.487710] driver: 'usb': driver_bound: bound to device 'usb3'
[    0.487723] bus: 'usb': really_probe: bound device usb3 to driver usb
[    0.487796] driver: 'exynos-ehci': driver_bound: bound to device '12110000.usb'
[    0.487812] bus: 'platform': really_probe: bound device 12110000.usb to driver exynos-ehci
[    0.487937] initcall ehci_exynos_init+0x0/0x54 returned 0 after 10437 usecs
[    0.487955] calling  ohci_hcd_mod_init+0x0/0x80 @ 1
[    0.487965] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    0.487985] initcall ohci_hcd_mod_init+0x0/0x80 returned 0 after 17 usecs
[    0.488002] calling  ohci_exynos_init+0x0/0x54 @ 1
[    0.488011] ohci-exynos: OHCI EXYNOS driver
[    0.488085] bus: 'platform': driver_probe_device: matched device 12120000.usb with driver exynos-ohci
[    0.488103] bus: 'platform': really_probe: probing driver exynos-ohci with device 12120000.usb
[    0.488179] exynos-ohci 12120000.usb: USB Host Controller
[    0.488204] exynos-ohci 12120000.usb: new USB bus registered, assigned bus number 4
[    0.488279] exynos-ohci 12120000.usb: irq 108, io mem 0x12120000
[    0.545832] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[    0.545845] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.545861] usb usb4: Product: USB Host Controller
[    0.545871] usb usb4: Manufacturer: Linux 4.3.0-rc5-next-20151013-dirty ohci_hcd
[    0.545886] usb usb4: SerialNumber: 12120000.usb
[    0.546171] bus: 'usb': driver_probe_device: matched device usb4 with driver usb
[    0.546188] bus: 'usb': really_probe: probing driver usb with device usb4
[    0.546322] bus: 'usb': driver_probe_device: matched device 4-0:1.0 with driver hub
[    0.546339] bus: 'usb': really_probe: probing driver hub with device 4-0:1.0
[    0.546368] hub 4-0:1.0: USB hub found
[    0.546394] hub 4-0:1.0: 3 ports detected
[    0.546583] driver: 'hub': driver_bound: bound to device '4-0:1.0'
[    0.546596] bus: 'usb': really_probe: bound device 4-0:1.0 to driver hub
[    0.546667] driver: 'usb': driver_bound: bound to device 'usb4'
[    0.546679] bus: 'usb': really_probe: bound device usb4 to driver usb
[    0.546777] driver: 'exynos-ohci': driver_bound: bound to device '12120000.usb'
[    0.546793] bus: 'platform': really_probe: bound device 12120000.usb to driver exynos-ohci
[    0.546905] initcall ohci_exynos_init+0x0/0x54 returned 0 after 57508 usecs
[    0.546923] calling  xhci_hcd_init+0x0/0x8 @ 1
[    0.546935] initcall xhci_hcd_init+0x0/0x8 returned 0 after 0 usecs
[    0.546951] calling  usb_storage_driver_init+0x0/0x38 @ 1
[    0.547053] usbcore: registered new interface driver usb-storage
[    0.547068] initcall usb_storage_driver_init+0x0/0x38 returned 0 after 100 usecs
[    0.547089] calling  usb3503_init+0x0/0x54 @ 1
[    0.547304] initcall usb3503_init+0x0/0x54 returned 0 after 196 usecs
[    0.547322] calling  gadget_cfs_init+0x0/0x20 @ 1
[    0.547369] initcall gadget_cfs_init+0x0/0x20 returned 0 after 31 usecs
[    0.547386] calling  ecmmod_init+0x0/0xc @ 1
[    0.547399] initcall ecmmod_init+0x0/0xc returned 0 after 1 usecs
[    0.547415] calling  gethmod_init+0x0/0xc @ 1
[    0.547427] initcall gethmod_init+0x0/0xc returned 0 after 0 usecs
[    0.547443] calling  rndismod_init+0x0/0xc @ 1
[    0.547455] initcall rndismod_init+0x0/0xc returned 0 after 0 usecs
[    0.547468] calling  eth_driver_init+0x0/0xc @ 1
[    0.547480] initcall eth_driver_init+0x0/0xc returned -19 after 1 usecs
[    0.547492] calling  serport_init+0x0/0x30 @ 1
[    0.547504] initcall serport_init+0x0/0x30 returned 0 after 0 usecs
[    0.547516] calling  input_leds_init+0x0/0xc @ 1
[    0.547529] initcall input_leds_init+0x0/0xc returned 0 after 1 usecs
[    0.547542] calling  mousedev_init+0x0/0x88 @ 1
[    0.547799] mousedev: PS/2 mouse device common for all mice
[    0.547813] initcall mousedev_init+0x0/0x88 returned 0 after 254 usecs
[    0.547827] calling  evdev_init+0x0/0xc @ 1
[    0.547839] initcall evdev_init+0x0/0xc returned 0 after 1 usecs
[    0.547851] calling  atkbd_init+0x0/0x18 @ 1
[    0.547929] initcall atkbd_init+0x0/0x18 returned 0 after 63 usecs
[    0.547944] calling  cros_ec_keyb_driver_init+0x0/0x10 @ 1
[    0.548078] initcall cros_ec_keyb_driver_init+0x0/0x10 returned 0 after 118 usecs
[    0.548097] calling  samsung_keypad_driver_init+0x0/0x10 @ 1
[    0.548243] initcall samsung_keypad_driver_init+0x0/0x10 returned 0 after 129 usecs
[    0.548261] calling  cyapa_driver_init+0x0/0x10 @ 1
[    0.548283] bus: 'i2c': driver_probe_device: matched device 1-0067 with driver cyapa
[    0.548304] bus: 'i2c': really_probe: probing driver cyapa with device 1-0067
[    0.548768] 1-0067 supply vcc not found, using dummy regulator
[    0.597006] input: Cypress APA Trackpad (cyapa) as /devices/platform/12c70000.i2c/i2c-1/1-0067/input/input0
[    0.597269] driver: 'cyapa': driver_bound: bound to device '1-0067'
[    0.597282] bus: 'i2c': really_probe: bound device 1-0067 to driver cyapa
[    0.597360] initcall cyapa_driver_init+0x0/0x10 returned 0 after 47935 usecs
[    0.597376] calling  mxt_driver_init+0x0/0x10 @ 1
[    0.597448] initcall mxt_driver_init+0x0/0x10 returned 0 after 57 usecs
[    0.597463] calling  max77686_rtc_driver_init+0x0/0x10 @ 1
[    0.597521] bus: 'platform': driver_probe_device: matched device max77686-rtc with driver max77686-rtc
[    0.597539] bus: 'platform': really_probe: probing driver max77686-rtc with device max77686-rtc
[    0.597572] max77686-rtc max77686-rtc: max77686_rtc_probe
[    0.697208] max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
[    0.697535] driver: 'max77686-rtc': driver_bound: bound to device 'max77686-rtc'
[    0.697552] bus: 'platform': really_probe: bound device max77686-rtc to driver max77686-rtc
[    0.697626] initcall max77686_rtc_driver_init+0x0/0x10 returned 0 after 97801 usecs
[    0.697645] calling  max77802_rtc_driver_init+0x0/0x10 @ 1
[    0.697741] initcall max77802_rtc_driver_init+0x0/0x10 returned 0 after 80 usecs
[    0.697759] calling  s3c_rtc_driver_init+0x0/0x10 @ 1
[    0.697795] bus: 'platform': driver_probe_device: matched device 101e0000.rtc with driver s3c-rtc
[    0.697812] bus: 'platform': really_probe: probing driver s3c-rtc with device 101e0000.rtc
[    0.697909] s3c-rtc 101e0000.rtc: failed to find rtc source clock
[    0.697936] platform 101e0000.rtc: Driver s3c-rtc requests probe deferral
[    0.697949] platform 101e0000.rtc: Added to deferred list
[    0.698141] initcall s3c_rtc_driver_init+0x0/0x10 returned 0 after 359 usecs
[    0.698156] calling  s5m_rtc_driver_init+0x0/0x10 @ 1
[    0.698246] initcall s5m_rtc_driver_init+0x0/0x10 returned 0 after 74 usecs
[    0.698260] calling  i2c_dev_init+0x0/0xe0 @ 1
[    0.698270] i2c /dev entries driver
[    0.699243] initcall i2c_dev_init+0x0/0xe0 returned 0 after 946 usecs
[    0.699259] calling  exynos5_i2c_driver_init+0x0/0x10 @ 1
[    0.699457] initcall exynos5_i2c_driver_init+0x0/0x10 returned 0 after 180 usecs
[    0.699477] calling  ec_i2c_tunnel_driver_init+0x0/0x10 @ 1
[    0.699602] initcall ec_i2c_tunnel_driver_init+0x0/0x10 returned 0 after 109 usecs
[    0.699621] calling  i2c_arbitrator_driver_init+0x0/0x10 @ 1
[    0.699699] bus: 'platform': driver_probe_device: matched device i2c-arbitrator with driver i2c-arb-gpio-challenge
[    0.699718] bus: 'platform': really_probe: probing driver i2c-arb-gpio-challenge with device i2c-arbitrator
[    0.699808] of_get_named_gpiod_flags: parsed 'our-claim-gpio' property of node '/i2c-arbitrator[0]' - status (0)
[    0.699839] of_get_named_gpiod_flags: parsed 'their-claim-gpios' property of node '/i2c-arbitrator[0]' - status (0)
[    0.699866] of_get_named_gpiod_flags: can't parse 'their-claim-gpios' property of node '/i2c-arbitrator[1]'
[    0.700358] bus: 'i2c': driver_probe_device: matched device 104-001e with driver cros-ec-i2c
[    0.700375] bus: 'i2c': really_probe: probing driver cros-ec-i2c with device 104-001e
[    0.708772] bus: 'platform': driver_probe_device: matched device i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller with driver cros-ec-keyb
[    0.708793] bus: 'platform': really_probe: probing driver cros-ec-keyb with device i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller
[    0.709002] input: cros_ec as /devices/platform/12ca0000.i2c/i2c-4/i2c-104/104-001e/i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller/input/input1
[    0.709218] driver: 'cros-ec-keyb': driver_bound: bound to device 'i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller'
[    0.709238] bus: 'platform': really_probe: bound device i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller to driver cros-ec-keyb
[    0.709261] cros-ec-i2c 104-001e: Chrome EC device registered
[    0.709272] driver: 'cros-ec-i2c': driver_bound: bound to device '104-001e'
[    0.709284] bus: 'i2c': really_probe: bound device 104-001e to driver cros-ec-i2c
[    0.709397] bus: 'i2c': driver_probe_device: matched device 104-0048 with driver tps65090
[    0.709414] bus: 'i2c': really_probe: probing driver tps65090 with device 104-0048
[    0.709500] tps65090 104-0048: No cache defaults, reading back from HW
[    0.713554] bus: 'platform': driver_probe_device: matched device tps65090-pmic with driver tps65090-pmic
[    0.713572] bus: 'platform': really_probe: probing driver tps65090-pmic with device tps65090-pmic
[    0.713701] of_get_named_gpiod_flags: can't parse 'dcdc-ext-control-gpios' property of node '/i2c-arbitrator/i2c@0/power-regulator[0]'
[    0.713719] of_get_named_gpiod_flags: can't parse 'dcdc-ext-control-gpios' property of node '/i2c-arbitrator/i2c@0/power-regulator[0]'
[    0.713737] of_get_named_gpiod_flags: can't parse 'dcdc-ext-control-gpios' property of node '/i2c-arbitrator/i2c@0/power-regulator[0]'
[    0.727363] driver: 'tps65090-pmic': driver_bound: bound to device 'tps65090-pmic'
[    0.727384] bus: 'platform': really_probe: bound device tps65090-pmic to driver tps65090-pmic
[    0.727564] driver: 'tps65090': driver_bound: bound to device '104-0048'
[    0.727578] bus: 'i2c': really_probe: bound device 104-0048 to driver tps65090
[    0.727614] i2c i2c-4: Added multiplexed i2c bus 104
[    0.727624] driver: 'i2c-arb-gpio-challenge': driver_bound: bound to device 'i2c-arbitrator'
[    0.727640] bus: 'platform': really_probe: bound device i2c-arbitrator to driver i2c-arb-gpio-challenge
[    0.727716] initcall i2c_arbitrator_driver_init+0x0/0x10 returned 0 after 27422 usecs
[    0.727737] calling  sbs_battery_driver_init+0x0/0x10 @ 1
[    0.727771] bus: 'i2c': driver_probe_device: matched device 104-000b with driver sbs-battery
[    0.727788] bus: 'i2c': really_probe: probing driver sbs-battery with device 104-000b
[    0.730061] sbs-battery 104-000b: sbs-battery: battery gas gauge device registered
[    0.730078] driver: 'sbs-battery': driver_bound: bound to device '104-000b'
[    0.730090] bus: 'i2c': really_probe: bound device 104-000b to driver sbs-battery
[    0.730159] initcall sbs_battery_driver_init+0x0/0x10 returned 0 after 2352 usecs
[    0.730178] calling  max17040_i2c_driver_init+0x0/0x10 @ 1
[    0.730248] initcall max17040_i2c_driver_init+0x0/0x10 returned 0 after 55 usecs
[    0.730267] calling  max17042_i2c_driver_init+0x0/0x10 @ 1
[    0.730344] initcall max17042_i2c_driver_init+0x0/0x10 returned 0 after 62 usecs
[    0.730363] calling  max14577_charger_driver_init+0x0/0x10 @ 1
[    0.730471] initcall max14577_charger_driver_init+0x0/0x10 returned 0 after 92 usecs
[    0.730490] calling  max77693_charger_driver_init+0x0/0x10 @ 1
[    0.730583] initcall max77693_charger_driver_init+0x0/0x10 returned 0 after 78 usecs
[    0.730602] calling  tps65090_charger_driver_init+0x0/0x10 @ 1
[    0.730712] bus: 'platform': driver_probe_device: matched device tps65090-charger with driver tps65090-charger
[    0.730731] bus: 'platform': really_probe: probing driver tps65090-charger with device tps65090-charger
[    0.732656] driver: 'tps65090-charger': driver_bound: bound to device 'tps65090-charger'
[    0.732674] bus: 'platform': really_probe: bound device tps65090-charger to driver tps65090-charger
[    0.732735] initcall tps65090_charger_driver_init+0x0/0x10 returned 0 after 2068 usecs
[    0.732754] calling  ina2xx_driver_init+0x0/0x10 @ 1
[    0.732829] initcall ina2xx_driver_init+0x0/0x10 returned 0 after 60 usecs
[    0.732844] calling  lm90_driver_init+0x0/0x10 @ 1
[    0.732917] initcall lm90_driver_init+0x0/0x10 returned 0 after 59 usecs
[    0.732932] calling  ntc_thermistor_driver_init+0x0/0x10 @ 1
[    0.733197] initcall ntc_thermistor_driver_init+0x0/0x10 returned 0 after 245 usecs
[    0.733216] calling  pwm_fan_driver_init+0x0/0x10 @ 1
[    0.733344] initcall pwm_fan_driver_init+0x0/0x10 returned 0 after 111 usecs
[    0.733359] calling  exynos_tmu_driver_init+0x0/0x10 @ 1
[    0.733457] bus: 'platform': driver_probe_device: matched device 10060000.tmu with driver exynos-tmu
[    0.733474] bus: 'platform': really_probe: probing driver exynos-tmu with device 10060000.tmu
[    0.733535] thermal thermal_zone0: failed to read out thermal zone (-22)
[    0.733583] 10060000.tmu supply vtmu not found, using dummy regulator
[    0.733713] driver: 'exynos-tmu': driver_bound: bound to device '10060000.tmu'
[    0.733730] bus: 'platform': really_probe: bound device 10060000.tmu to driver exynos-tmu
[    0.733960] initcall exynos_tmu_driver_init+0x0/0x10 returned 0 after 573 usecs
[    0.733981] calling  s3c2410wdt_driver_init+0x0/0x10 @ 1
[    0.734041] bus: 'platform': driver_probe_device: matched device 101d0000.watchdog with driver s3c2410-wdt
[    0.734059] bus: 'platform': really_probe: probing driver s3c2410-wdt with device 101d0000.watchdog
[    0.734400] s3c2410-wdt 101d0000.watchdog: watchdog inactive, reset disabled, irq disabled
[    0.734418] driver: 's3c2410-wdt': driver_bound: bound to device '101d0000.watchdog'
[    0.734433] bus: 'platform': really_probe: bound device 101d0000.watchdog to driver s3c2410-wdt
[    0.734587] initcall s3c2410wdt_driver_init+0x0/0x10 returned 0 after 579 usecs
[    0.734606] calling  dm_init+0x0/0x54 @ 1
[    0.734926] device-mapper: ioctl: 4.33.0-ioctl (2015-8-18) initialised: dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
[    0.734945] initcall dm_init+0x0/0x54 returned 0 after 319 usecs
[    0.734960] calling  cpufreq_stats_init+0x0/0xe8 @ 1
[    0.734974] initcall cpufreq_stats_init+0x0/0xe8 returned 0 after 2 usecs
[    0.734989] calling  dt_cpufreq_platdrv_init+0x0/0x10 @ 1
[    0.735012] bus: 'platform': driver_probe_device: matched device cpufreq-dt with driver cpufreq-dt
[    0.735029] bus: 'platform': really_probe: probing driver cpufreq-dt with device cpufreq-dt
[    0.736234] driver: 'cpufreq-dt': driver_bound: bound to device 'cpufreq-dt'
[    0.736249] bus: 'platform': really_probe: bound device cpufreq-dt to driver cpufreq-dt
[    0.736348] initcall dt_cpufreq_platdrv_init+0x0/0x10 returned 0 after 1313 usecs
[    0.736368] calling  exynos_cpufreq_platdrv_init+0x0/0x10 @ 1
[    0.736517] initcall exynos_cpufreq_platdrv_init+0x0/0x10 returned 0 after 131 usecs
[    0.736537] calling  exynos_cpuidle_driver_init+0x0/0x10 @ 1
[    0.736558] bus: 'platform': driver_probe_device: matched device exynos_cpuidle with driver exynos_cpuidle
[    0.736576] bus: 'platform': really_probe: probing driver exynos_cpuidle with device exynos_cpuidle
[    0.736860] driver: 'exynos_cpuidle': driver_bound: bound to device 'exynos_cpuidle'
[    0.736878] bus: 'platform': really_probe: bound device exynos_cpuidle to driver exynos_cpuidle
[    0.736979] initcall exynos_cpuidle_driver_init+0x0/0x10 returned 0 after 418 usecs
[    0.736999] calling  mmc_blk_init+0x0/0x98 @ 1
[    0.737056] initcall mmc_blk_init+0x0/0x98 returned 0 after 43 usecs
[    0.737072] calling  sdhci_drv_init+0x0/0x24 @ 1
[    0.737082] sdhci: Secure Digital Host Controller Interface driver
[    0.737092] sdhci: Copyright(c) Pierre Ossman
[    0.737103] initcall sdhci_drv_init+0x0/0x24 returned 0 after 18 usecs
[    0.737124] calling  sdhci_s3c_driver_init+0x0/0x10 @ 1
[    0.737293] initcall sdhci_s3c_driver_init+0x0/0x10 returned 0 after 151 usecs
[    0.737312] calling  dw_mci_init+0x0/0x18 @ 1
[    0.737321] Synopsys Designware Multimedia Card Interface Driver
[    0.737333] initcall dw_mci_init+0x0/0x18 returned 0 after 9 usecs
[    0.737348] calling  dw_mci_pltfm_driver_init+0x0/0x10 @ 1
[    0.737504] initcall dw_mci_pltfm_driver_init+0x0/0x10 returned 0 after 139 usecs
[    0.737523] calling  dw_mci_exynos_pltfm_driver_init+0x0/0x10 @ 1
[    0.737752] bus: 'platform': driver_probe_device: matched device 12200000.mmc with driver dwmmc_exynos
[    0.737770] bus: 'platform': really_probe: probing driver dwmmc_exynos with device 12200000.mmc
[    0.738028] dwmmc_exynos 12200000.mmc: IDMAC supports 32-bit address mode.
[    0.738082] dwmmc_exynos 12200000.mmc: Using internal DMA controller.
[    0.738098] dwmmc_exynos 12200000.mmc: Version ID is 241a
[    0.738136] dwmmc_exynos 12200000.mmc: DW MMC controller at irq 105,32 bit host data width,128 deep fifo
[    0.738208] dwmmc_exynos 12200000.mmc: No vmmc regulator found
[    0.738220] dwmmc_exynos 12200000.mmc: No vqmmc regulator found
[    0.738237] dwmmc_exynos 12200000.mmc: GPIO lookup for consumer cd
[    0.738248] dwmmc_exynos 12200000.mmc: using device tree for GPIO lookup
[    0.738261] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/mmc@12200000[0]'
[    0.738277] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/mmc@12200000[0]'
[    0.738293] dwmmc_exynos 12200000.mmc: using lookup tables for GPIO lookup
[    0.738305] dwmmc_exynos 12200000.mmc: lookup for GPIO cd failed
[    0.738317] dwmmc_exynos 12200000.mmc: GPIO lookup for consumer wp
[    0.738328] dwmmc_exynos 12200000.mmc: using device tree for GPIO lookup
[    0.738344] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/mmc@12200000[0]'
[    0.738359] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/mmc@12200000[0]'
[    0.738375] dwmmc_exynos 12200000.mmc: using lookup tables for GPIO lookup
[    0.738386] dwmmc_exynos 12200000.mmc: lookup for GPIO wp failed
[    0.766769] dwmmc_exynos 12200000.mmc: 1 slots initialized
[    0.766782] driver: 'dwmmc_exynos': driver_bound: bound to device '12200000.mmc'
[    0.766799] bus: 'platform': really_probe: bound device 12200000.mmc to driver dwmmc_exynos
[    0.766820] bus: 'platform': driver_probe_device: matched device 12220000.mmc with driver dwmmc_exynos
[    0.766837] bus: 'platform': really_probe: probing driver dwmmc_exynos with device 12220000.mmc
[    0.767133] dwmmc_exynos 12220000.mmc: IDMAC supports 32-bit address mode.
[    0.767170] dwmmc_exynos 12220000.mmc: Using internal DMA controller.
[    0.767186] dwmmc_exynos 12220000.mmc: Version ID is 241a
[    0.767220] dwmmc_exynos 12220000.mmc: DW MMC controller at irq 106,32 bit host data width,128 deep fifo
[    0.767287] dwmmc_exynos 12220000.mmc: No vmmc regulator found
[    0.767298] dwmmc_exynos 12220000.mmc: No vqmmc regulator found
[    0.767315] dwmmc_exynos 12220000.mmc: GPIO lookup for consumer cd
[    0.767326] dwmmc_exynos 12220000.mmc: using device tree for GPIO lookup
[    0.767338] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/mmc@12220000[0]'
[    0.767355] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/mmc@12220000[0]'
[    0.767370] dwmmc_exynos 12220000.mmc: using lookup tables for GPIO lookup
[    0.767382] dwmmc_exynos 12220000.mmc: lookup for GPIO cd failed
[    0.767394] dwmmc_exynos 12220000.mmc: GPIO lookup for consumer wp
[    0.767405] dwmmc_exynos 12220000.mmc: using device tree for GPIO lookup
[    0.767420] of_get_named_gpiod_flags: parsed 'wp-gpios' property of node '/mmc@12220000[0]' - status (0)
[    0.767449] dwmmc_exynos 12220000.mmc: Got WP GPIO
[    0.781730] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[    0.796758] dwmmc_exynos 12220000.mmc: 1 slots initialized
[    0.796773] driver: 'dwmmc_exynos': driver_bound: bound to device '12220000.mmc'
[    0.796789] bus: 'platform': really_probe: bound device 12220000.mmc to driver dwmmc_exynos
[    0.796810] bus: 'platform': driver_probe_device: matched device 12230000.mmc with driver dwmmc_exynos
[    0.796827] bus: 'platform': really_probe: probing driver dwmmc_exynos with device 12230000.mmc
[    0.797098] dwmmc_exynos 12230000.mmc: IDMAC supports 32-bit address mode.
[    0.797138] dwmmc_exynos 12230000.mmc: Using internal DMA controller.
[    0.797154] dwmmc_exynos 12230000.mmc: Version ID is 241a
[    0.797188] dwmmc_exynos 12230000.mmc: DW MMC controller at irq 107,32 bit host data width,128 deep fifo
[    0.797250] dwmmc_exynos 12230000.mmc: No vmmc regulator found
[    0.797261] dwmmc_exynos 12230000.mmc: No vqmmc regulator found
[    0.797277] dwmmc_exynos 12230000.mmc: GPIO lookup for consumer cd
[    0.797289] dwmmc_exynos 12230000.mmc: using device tree for GPIO lookup
[    0.797301] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/mmc@12230000[0]'
[    0.797318] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/mmc@12230000[0]'
[    0.797333] dwmmc_exynos 12230000.mmc: using lookup tables for GPIO lookup
[    0.797345] dwmmc_exynos 12230000.mmc: lookup for GPIO cd failed
[    0.797357] dwmmc_exynos 12230000.mmc: GPIO lookup for consumer wp
[    0.797368] dwmmc_exynos 12230000.mmc: using device tree for GPIO lookup
[    0.797379] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/mmc@12230000[0]'
[    0.797395] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/mmc@12230000[0]'
[    0.797410] dwmmc_exynos 12230000.mmc: using lookup tables for GPIO lookup
[    0.797422] dwmmc_exynos 12230000.mmc: lookup for GPIO wp failed
[    0.797554] platform 12230000.mmc: Driver dwmmc_exynos requests probe deferral
[    0.797570] platform 12230000.mmc: Added to deferred list
[    0.797714] initcall dw_mci_exynos_pltfm_driver_init+0x0/0x10 returned 0 after 58764 usecs
[    0.797735] calling  gpio_led_driver_init+0x0/0x10 @ 1
[    0.797862] initcall gpio_led_driver_init+0x0/0x10 returned 0 after 111 usecs
[    0.797879] calling  led_pwm_driver_init+0x0/0x10 @ 1
[    0.797990] initcall led_pwm_driver_init+0x0/0x10 returned 0 after 95 usecs
[    0.798006] calling  heartbeat_trig_init+0x0/0x40 @ 1
[    0.798021] initcall heartbeat_trig_init+0x0/0x40 returned 0 after 2 usecs
[    0.798035] calling  hid_init+0x0/0x54 @ 1
[    0.798086] initcall hid_init+0x0/0x54 returned 0 after 38 usecs
[    0.798101] calling  hid_generic_init+0x0/0x18 @ 1
[    0.798146] initcall hid_generic_init+0x0/0x18 returned 0 after 32 usecs
[    0.798161] calling  a4_driver_init+0x0/0x18 @ 1
[    0.798201] initcall a4_driver_init+0x0/0x18 returned 0 after 26 usecs
[    0.798216] calling  apple_driver_init+0x0/0x18 @ 1
[    0.798266] initcall apple_driver_init+0x0/0x18 returned 0 after 37 usecs
[    0.798282] calling  belkin_driver_init+0x0/0x18 @ 1
[    0.798326] initcall belkin_driver_init+0x0/0x18 returned 0 after 31 usecs
[    0.798342] calling  ch_driver_init+0x0/0x18 @ 1
[    0.798380] initcall ch_driver_init+0x0/0x18 returned 0 after 25 usecs
[    0.798395] calling  ch_driver_init+0x0/0x18 @ 1
[    0.798432] initcall ch_driver_init+0x0/0x18 returned 0 after 25 usecs
[    0.798447] calling  cp_driver_init+0x0/0x18 @ 1
[    0.798484] initcall cp_driver_init+0x0/0x18 returned 0 after 25 usecs
[    0.798499] calling  ez_driver_init+0x0/0x18 @ 1
[    0.798538] initcall ez_driver_init+0x0/0x18 returned 0 after 26 usecs
[    0.798553] calling  ks_driver_init+0x0/0x18 @ 1
[    0.798590] initcall ks_driver_init+0x0/0x18 returned 0 after 25 usecs
[    0.798605] calling  lg_driver_init+0x0/0x18 @ 1
[    0.798642] initcall lg_driver_init+0x0/0x18 returned 0 after 25 usecs
[    0.798657] calling  ms_driver_init+0x0/0x18 @ 1
[    0.798695] initcall ms_driver_init+0x0/0x18 returned 0 after 25 usecs
[    0.798710] calling  mr_driver_init+0x0/0x18 @ 1
[    0.798750] initcall mr_driver_init+0x0/0x18 returned 0 after 28 usecs
[    0.798765] calling  hid_init+0x0/0x5c @ 1
[    0.798829] usbcore: registered new interface driver usbhid
[    0.798840] usbhid: USB HID core driver
[    0.798851] initcall hid_init+0x0/0x5c returned 0 after 72 usecs
[    0.798866] calling  cros_ec_dev_init+0x0/0xd4 @ 1
[    0.798938] bus: 'platform': driver_probe_device: matched device cros-ec-ctl.3.auto with driver cros-ec-ctl
[    0.798956] bus: 'platform': really_probe: probing driver cros-ec-ctl with device cros-ec-ctl.3.auto
[    0.799149] driver: 'cros-ec-ctl': driver_bound: bound to device 'cros-ec-ctl.3.auto'
[    0.799167] bus: 'platform': really_probe: bound device cros-ec-ctl.3.auto to driver cros-ec-ctl
[    0.799207] initcall cros_ec_dev_init+0x0/0xd4 returned 0 after 320 usecs
[    0.799224] calling  max77686_clk_driver_init+0x0/0x10 @ 1
[    0.799282] bus: 'platform': driver_probe_device: matched device max77686-clk with driver max77686-clk
[    0.799300] bus: 'platform': really_probe: probing driver max77686-clk with device max77686-clk
[    0.799407] driver: 'max77686-clk': driver_bound: bound to device 'max77686-clk'
[    0.799423] bus: 'platform': really_probe: bound device max77686-clk to driver max77686-clk
[    0.799475] initcall max77686_clk_driver_init+0x0/0x10 returned 0 after 230 usecs
[    0.799495] calling  max77802_clk_driver_init+0x0/0x10 @ 1
[    0.799570] initcall max77802_clk_driver_init+0x0/0x10 returned 0 after 60 usecs
[    0.799593] calling  extcon_class_init+0x0/0x20 @ 1
[    0.799622] initcall extcon_class_init+0x0/0x20 returned 0 after 15 usecs
[    0.799639] calling  max14577_muic_driver_init+0x0/0x10 @ 1
[    0.799714] initcall max14577_muic_driver_init+0x0/0x10 returned 0 after 59 usecs
[    0.799736] calling  max77693_muic_driver_init+0x0/0x10 @ 1
[    0.799811] initcall max77693_muic_driver_init+0x0/0x10 returned 0 after 61 usecs
[    0.799832] calling  exynos_adc_driver_init+0x0/0x10 @ 1
[    0.800196] initcall exynos_adc_driver_init+0x0/0x10 returned 0 after 341 usecs
[    0.800219] calling  alsa_timer_init+0x0/0x200 @ 1
[    0.800366] initcall alsa_timer_init+0x0/0x200 returned 0 after 129 usecs
[    0.800385] calling  alsa_pcm_init+0x0/0x6c @ 1
[    0.800402] initcall alsa_pcm_init+0x0/0x6c returned 0 after 4 usecs
[    0.800419] calling  snd_compress_init+0x0/0x8 @ 1
[    0.800431] initcall snd_compress_init+0x0/0x8 returned 0 after 0 usecs
[    0.800447] calling  snd_soc_init+0x0/0x11c @ 1
[    0.800636] bus: 'platform': driver_probe_device: matched device snd-soc-dummy with driver snd-soc-dummy
[    0.800654] bus: 'platform': really_probe: probing driver snd-soc-dummy with device snd-soc-dummy
[    0.800697] driver: 'snd-soc-dummy': driver_bound: bound to device 'snd-soc-dummy'
[    0.800714] bus: 'platform': really_probe: bound device snd-soc-dummy to driver snd-soc-dummy
[    0.800818] initcall snd_soc_init+0x0/0x11c returned 0 after 349 usecs
[    0.800845] calling  max98090_i2c_driver_init+0x0/0x10 @ 1
[    0.800912] initcall max98090_i2c_driver_init+0x0/0x10 returned 0 after 51 usecs
[    0.800934] calling  max98095_i2c_driver_init+0x0/0x10 @ 1
[    0.800958] bus: 'i2c': driver_probe_device: matched device 7-0011 with driver max98095
[    0.800979] bus: 'i2c': really_probe: probing driver max98095 with device 7-0011
[    0.801145] driver: 'max98095': driver_bound: bound to device '7-0011'
[    0.801159] bus: 'i2c': really_probe: bound device 7-0011 to driver max98095
[    0.801212] initcall max98095_i2c_driver_init+0x0/0x10 returned 0 after 256 usecs
[    0.801234] calling  asoc_simple_card_init+0x0/0x10 @ 1
[    0.801356] initcall asoc_simple_card_init+0x0/0x10 returned 0 after 105 usecs
[    0.801378] calling  samsung_i2s_driver_init+0x0/0x10 @ 1
[    0.801468] bus: 'platform': driver_probe_device: matched device 3830000.i2s with driver samsung-i2s
[    0.801485] bus: 'platform': really_probe: probing driver samsung-i2s with device 3830000.i2s
[    0.801739] bus: 'platform': driver_probe_device: matched device samsung-i2s-sec with driver samsung-i2s
[    0.801758] bus: 'platform': really_probe: probing driver samsung-i2s with device samsung-i2s-sec
[    0.801798] driver: 'samsung-i2s': driver_bound: bound to device 'samsung-i2s-sec'
[    0.801814] bus: 'platform': really_probe: bound device samsung-i2s-sec to driver samsung-i2s
[    0.801840] driver: 'samsung-i2s': driver_bound: bound to device '3830000.i2s'
[    0.801855] bus: 'platform': really_probe: bound device 3830000.i2s to driver samsung-i2s
[    0.801982] initcall samsung_i2s_driver_init+0x0/0x10 returned 0 after 574 usecs
[    0.802004] calling  asoc_idma_driver_init+0x0/0x10 @ 1
[    0.802078] initcall asoc_idma_driver_init+0x0/0x10 returned 0 after 59 usecs
[    0.802096] calling  snow_driver_init+0x0/0x10 @ 1
[    0.802200] bus: 'platform': driver_probe_device: matched device sound with driver snow-audio
[    0.802217] bus: 'platform': really_probe: probing driver snow-audio with device sound
[    0.825682] mmc0: MAN_BKOPS_EN bit is not set
[    0.828300] mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
[    0.829748] mmc_host mmc0: Bus speed (slot 0) = 100000000Hz (slot req 52000000Hz, actual 50000000HZ div = 1)
[    0.830247] mmc0: new DDR MMC card at address 0001
[    0.830645] bus: 'mmc': driver_probe_device: matched device mmc0:0001 with driver mmcblk
[    0.830694] bus: 'mmc': really_probe: probing driver mmcblk with device mmc0:0001
[    0.831127] mmcblk0: mmc0:0001 SEM16G 14.6 GiB 
[    0.831432] mmcblk0boot0: mmc0:0001 SEM16G partition 1 2.00 MiB
[    0.831814] mmcblk0boot1: mmc0:0001 SEM16G partition 2 2.00 MiB
[    0.832102] mmcblk0rpmb: mmc0:0001 SEM16G partition 3 128 KiB
[    0.836941]  mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12
[    0.844786] driver: 'mmcblk': driver_bound: bound to device 'mmc0:0001'
[    0.844826] bus: 'mmc': really_probe: bound device mmc0:0001 to driver mmcblk
[    0.870562] max98095 7-0011: Hardware revision: C
[    0.879992] snow-audio sound: HiFi <-> 3830000.i2s mapping ok
[    0.880747] max98095 7-0011: ASoC: mux External MIC has no paths
[    0.880794] max98095 7-0011: ASoC: mux Linein Mux has no paths
[    0.883662] driver: 'snow-audio': driver_bound: bound to device 'sound'
[    0.883702] bus: 'platform': really_probe: bound device sound to driver snow-audio
[    0.883860] initcall snow_driver_init+0x0/0x10 returned 0 after 79820 usecs
[    0.883913] calling  odroidx2_audio_driver_init+0x0/0x10 @ 1
[    0.884323] initcall odroidx2_audio_driver_init+0x0/0x10 returned 0 after 361 usecs
[    0.884375] calling  sock_diag_init+0x0/0x50 @ 1
[    0.884457] initcall sock_diag_init+0x0/0x50 returned 0 after 46 usecs
[    0.884500] calling  gre_offload_init+0x0/0x10 @ 1
[    0.884533] initcall gre_offload_init+0x0/0x10 returned 0 after 1 usecs
[    0.884571] calling  sysctl_ipv4_init+0x0/0x54 @ 1
[    0.884768] initcall sysctl_ipv4_init+0x0/0x54 returned 0 after 160 usecs
[    0.884808] calling  xfrm4_beet_init+0x0/0x10 @ 1
[    0.884842] initcall xfrm4_beet_init+0x0/0x10 returned 0 after 2 usecs
[    0.884880] calling  tunnel4_init+0x0/0x70 @ 1
[    0.884911] initcall tunnel4_init+0x0/0x70 returned 0 after 1 usecs
[    0.884949] calling  xfrm4_transport_init+0x0/0x10 @ 1
[    0.884981] initcall xfrm4_transport_init+0x0/0x10 returned 0 after 1 usecs
[    0.885020] calling  xfrm4_mode_tunnel_init+0x0/0x10 @ 1
[    0.885053] initcall xfrm4_mode_tunnel_init+0x0/0x10 returned 0 after 1 usecs
[    0.885091] calling  inet_diag_init+0x0/0x88 @ 1
[    0.885128] initcall inet_diag_init+0x0/0x88 returned 0 after 6 usecs
[    0.885165] calling  tcp_diag_init+0x0/0xc @ 1
[    0.885197] initcall tcp_diag_init+0x0/0xc returned 0 after 2 usecs
[    0.885234] calling  cubictcp_register+0x0/0x64 @ 1
[    0.885267] initcall cubictcp_register+0x0/0x64 returned 0 after 2 usecs
[    0.885305] calling  inet6_init+0x0/0x2c0 @ 1
[    0.887211] NET: Registered protocol family 10
[    0.893144] initcall inet6_init+0x0/0x2c0 returned 0 after 7619 usecs
[    0.893192] calling  xfrm6_transport_init+0x0/0x10 @ 1
[    0.893227] initcall xfrm6_transport_init+0x0/0x10 returned 0 after 1 usecs
[    0.893268] calling  xfrm6_mode_tunnel_init+0x0/0x10 @ 1
[    0.893302] initcall xfrm6_mode_tunnel_init+0x0/0x10 returned 0 after 1 usecs
[    0.893343] calling  xfrm6_beet_init+0x0/0x10 @ 1
[    0.893375] initcall xfrm6_beet_init+0x0/0x10 returned 0 after 1 usecs
[    0.893414] calling  sit_init+0x0/0xc8 @ 1
[    0.893439] sit: IPv6 over IPv4 tunneling driver
[    0.894527] initcall sit_init+0x0/0xc8 returned 0 after 1052 usecs
[    0.894570] calling  packet_init+0x0/0x48 @ 1
[    0.894600] NET: Registered protocol family 17
[    0.894648] initcall packet_init+0x0/0x48 returned 0 after 43 usecs
[    0.894688] calling  ipsec_pfkey_init+0x0/0x78 @ 1
[    0.894731] NET: Registered protocol family 15
[    0.894764] initcall ipsec_pfkey_init+0x0/0x78 returned 0 after 42 usecs
[    0.894987] calling  init_machine_late+0x0/0x98 @ 1
[    0.895378] initcall init_machine_late+0x0/0x98 returned 0 after 349 usecs
[    0.895422] calling  swp_emulation_init+0x0/0x6c @ 1
[    0.895465] Registering SWP/SWPB emulation handler
[    0.895500] initcall swp_emulation_init+0x0/0x6c returned 0 after 44 usecs
[    0.895544] calling  bL_switcher_init+0x0/0xb8 @ 1
[    0.895578] initcall bL_switcher_init+0x0/0xb8 returned -19 after 1 usecs
[    0.895616] calling  init_oops_id+0x0/0x40 @ 1
[    0.895657] initcall init_oops_id+0x0/0x40 returned 0 after 10 usecs
[    0.895704] calling  sched_init_debug+0x0/0x3c @ 1
[    0.895754] initcall sched_init_debug+0x0/0x3c returned 0 after 15 usecs
[    0.895800] calling  pm_qos_power_init+0x0/0xb0 @ 1
[    0.896866] initcall pm_qos_power_init+0x0/0xb0 returned 0 after 1004 usecs
[    0.896919] calling  pm_debugfs_init+0x0/0x38 @ 1
[    0.896966] initcall pm_debugfs_init+0x0/0x38 returned 0 after 12 usecs
[    0.897004] calling  printk_late_init+0x0/0x5c @ 1
[    0.897041] initcall printk_late_init+0x0/0x5c returned 0 after 6 usecs
[    0.897080] calling  tk_debug_sleep_time_init+0x0/0x50 @ 1
[    0.897124] initcall tk_debug_sleep_time_init+0x0/0x50 returned 0 after 11 usecs
[    0.897177] calling  fault_around_debugfs+0x0/0x4c @ 1
[    0.897234] initcall fault_around_debugfs+0x0/0x4c returned 0 after 23 usecs
[    0.897280] calling  max_swapfiles_check+0x0/0x8 @ 1
[    0.897313] initcall max_swapfiles_check+0x0/0x8 returned 0 after 0 usecs
[    0.897351] calling  prandom_reseed+0x0/0x44 @ 1
[    0.897410] initcall prandom_reseed+0x0/0x44 returned 0 after 25 usecs
[    0.897451] calling  fb_logo_late_init+0x0/0x18 @ 1
[    0.897483] initcall fb_logo_late_init+0x0/0x18 returned 0 after 0 usecs
[    0.897528] calling  deferred_probe_initcall+0x0/0x88 @ 1
[    0.897706] platform backlight: Retrying from deferred list
[    0.897819] bus: 'platform': driver_probe_device: matched device backlight with driver pwm-backlight
[    0.897867] bus: 'platform': really_probe: probing driver pwm-backlight with device backlight
[    0.898052] pwm-backlight backlight: GPIO lookup for consumer enable
[    0.898087] pwm-backlight backlight: using device tree for GPIO lookup
[    0.898134] of_get_named_gpiod_flags: parsed 'enable-gpios' property of node '/backlight[0]' - status (0)
[    0.898298] vcd_led: supplied by vbat-supply
[    0.900171] driver: 'pwm-backlight': driver_bound: bound to device 'backlight'
[    0.900227] bus: 'platform': really_probe: bound device backlight to driver pwm-backlight
[    0.900283] platform 145b0000.dp-controller: Retrying from deferred list
[    0.900416] bus: 'platform': driver_probe_device: matched device 145b0000.dp-controller with driver exynos-dp
[    0.900462] bus: 'platform': really_probe: probing driver exynos-dp with device 145b0000.dp-controller
[    0.901117] platform 145b0000.dp-controller: Driver exynos-dp requests probe deferral
[    0.901165] platform 145b0000.dp-controller: Added to deferred list
[    0.901386] platform 14530000.hdmi: Retrying from deferred list
[    0.901527] bus: 'platform': driver_probe_device: matched device 14530000.hdmi with driver exynos-hdmi
[    0.901572] bus: 'platform': really_probe: probing driver exynos-hdmi with device 14530000.hdmi
[    0.902450] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of node '/hdmi[0]' - status (0)
[    0.903637] video_mid_1a: supplied by vbat-supply
[    0.905765] driver: 'exynos-hdmi': driver_bound: bound to device '14530000.hdmi'
[    0.905817] bus: 'platform': really_probe: bound device 14530000.hdmi to driver exynos-hdmi
[    0.905899] platform panel: Retrying from deferred list
[    0.906062] bus: 'platform': driver_probe_device: matched device panel with driver panel-simple
[    0.906109] bus: 'platform': really_probe: probing driver panel-simple with device panel
[    0.906306] lcd_vdd: supplied by vbat-supply
[    0.907007] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[    0.907046] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    0.907234] panel-simple panel: GPIO lookup for consumer enable
[    0.907272] panel-simple panel: using device tree for GPIO lookup
[    0.907306] of_get_named_gpiod_flags: can't parse 'enable-gpios' property of node '/panel[0]'
[    0.907351] of_get_named_gpiod_flags: can't parse 'enable-gpio' property of node '/panel[0]'
[    0.907394] panel-simple panel: using lookup tables for GPIO lookup
[    0.907427] panel-simple panel: lookup for GPIO enable failed
[    0.907558] driver: 'panel-simple': driver_bound: bound to device 'panel'
[    0.907595] bus: 'platform': really_probe: bound device panel to driver panel-simple
[    0.907651] i2c 7-0020: Retrying from deferred list
[    0.907661] bus: 'usb': driver_probe_device: matched device 1-1 with driver usb
[    0.907669] bus: 'usb': really_probe: probing driver usb with device 1-1
[    0.907785] bus: 'i2c': driver_probe_device: matched device 7-0020 with driver nxp,ptn3460
[    0.907831] bus: 'i2c': really_probe: probing driver nxp,ptn3460 with device 7-0020
[    0.907981] nxp,ptn3460 7-0020: GPIO lookup for consumer powerdown
[    0.908014] nxp,ptn3460 7-0020: using device tree for GPIO lookup
[    0.908056] of_get_named_gpiod_flags: parsed 'powerdown-gpios' property of node '/i2c@12CD0000/lvds-bridge@20[0]' - status (0)
[    0.908120] nxp,ptn3460 7-0020: GPIO lookup for consumer reset
[    0.908150] nxp,ptn3460 7-0020: using device tree for GPIO lookup
[    0.908190] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/i2c@12CD0000/lvds-bridge@20[0]' - status (0)
[    0.908252] driver: 'nxp,ptn3460': driver_bound: bound to device '7-0020'
[    0.908286] bus: 'i2c': really_probe: bound device 7-0020 to driver nxp,ptn3460
[    0.908373] platform 101e0000.rtc: Retrying from deferred list
[    0.908572] bus: 'platform': driver_probe_device: matched device 101e0000.rtc with driver s3c-rtc
[    0.908616] bus: 'platform': really_probe: probing driver s3c-rtc with device 101e0000.rtc
[    0.909091] s3c-rtc 101e0000.rtc: rtc disabled, re-enabling
[    0.909614] s3c-rtc 101e0000.rtc: rtc core: registered s3c as rtc1
[    0.909765] driver: 's3c-rtc': driver_bound: bound to device '101e0000.rtc'
[    0.909803] bus: 'platform': really_probe: bound device 101e0000.rtc to driver s3c-rtc
[    0.909858] platform 12230000.mmc: Retrying from deferred list
[    0.910111] bus: 'platform': driver_probe_device: matched device 12230000.mmc with driver dwmmc_exynos
[    0.910156] bus: 'platform': really_probe: probing driver dwmmc_exynos with device 12230000.mmc
[    0.910775] dwmmc_exynos 12230000.mmc: IDMAC supports 32-bit address mode.
[    0.910892] dwmmc_exynos 12230000.mmc: Using internal DMA controller.
[    0.910929] dwmmc_exynos 12230000.mmc: Version ID is 241a
[    0.910983] dwmmc_exynos 12230000.mmc: DW MMC controller at irq 107,32 bit host data width,128 deep fifo
[    0.911167] dwmmc_exynos 12230000.mmc: No vmmc regulator found
[    0.911198] dwmmc_exynos 12230000.mmc: No vqmmc regulator found
[    0.911241] dwmmc_exynos 12230000.mmc: GPIO lookup for consumer cd
[    0.911273] dwmmc_exynos 12230000.mmc: using device tree for GPIO lookup
[    0.911306] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/mmc@12230000[0]'
[    0.911352] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/mmc@12230000[0]'
[    0.911394] dwmmc_exynos 12230000.mmc: using lookup tables for GPIO lookup
[    0.911427] dwmmc_exynos 12230000.mmc: lookup for GPIO cd failed
[    0.911461] dwmmc_exynos 12230000.mmc: GPIO lookup for consumer wp
[    0.911492] dwmmc_exynos 12230000.mmc: using device tree for GPIO lookup
[    0.911524] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/mmc@12230000[0]'
[    0.911567] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/mmc@12230000[0]'
[    0.911609] dwmmc_exynos 12230000.mmc: using lookup tables for GPIO lookup
[    0.911641] dwmmc_exynos 12230000.mmc: lookup for GPIO wp failed
[    0.911898] platform mmc3_pwrseq: GPIO lookup for consumer reset
[    0.911930] platform mmc3_pwrseq: using device tree for GPIO lookup
[    0.911970] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/mmc3_pwrseq[0]' - status (0)
[    0.912030] platform mmc3_pwrseq: GPIO lookup for consumer reset
[    0.912059] platform mmc3_pwrseq: using device tree for GPIO lookup
[    0.912102] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/mmc3_pwrseq[1]' - status (0)
[    0.912160] dwmmc_exynos 12230000.mmc: allocated mmc-pwrseq
[    0.924495] bus: 'usb': driver_probe_device: matched device 1-1:1.0 with driver hub
[    0.924546] bus: 'usb': really_probe: probing driver hub with device 1-1:1.0
[    0.924638] hub 1-1:1.0: USB hub found
[    0.924777] hub 1-1:1.0: 5 ports detected
[    0.941824] dwmmc_exynos 12230000.mmc: 1 slots initialized
[    0.941859] driver: 'dwmmc_exynos': driver_bound: bound to device '12230000.mmc'
[    0.941905] bus: 'platform': really_probe: bound device 12230000.mmc to driver dwmmc_exynos
[    0.941961] platform 145b0000.dp-controller: Retrying from deferred list
[    0.942096] bus: 'platform': driver_probe_device: matched device 145b0000.dp-controller with driver exynos-dp
[    0.942142] bus: 'platform': really_probe: probing driver exynos-dp with device 145b0000.dp-controller
[    0.944121] exynos-drm exynos-drm: bound 14400000.fimd (ops fimd_component_ops)
[    0.944279] of_get_named_gpiod_flags: parsed 'samsung,hpd-gpio' property of node '/dp-controller@145B0000[0]' - status (0)
[    0.945111] exynos-drm exynos-drm: bound 145b0000.dp-controller (ops exynos_dp_ops)
[    0.945297] exynos-drm exynos-drm: bound 14450000.mixer (ops mixer_component_ops)
[    0.945776] exynos-drm exynos-drm: bound 14530000.hdmi (ops hdmi_component_ops)
[    0.945820] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    0.945849] [drm] No driver support for vblank timestamp query.
[    0.957614] driver: 'hub': driver_bound: bound to device '1-1:1.0'
[    0.957657] bus: 'usb': really_probe: bound device 1-1:1.0 to driver hub
[    0.957699] driver: 'usb': driver_bound: bound to device '1-1'
[    0.957735] bus: 'usb': really_probe: bound device 1-1 to driver usb
[    0.998673] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[    1.005565] mmc2: new high speed SDIO card at address 0001
[    1.005772] bus: 'mmc': driver_probe_device: matched device mmc2:0001 with driver mmcblk
[    1.005819] bus: 'mmc': really_probe: probing driver mmcblk with device mmc2:0001
[    1.005927] mmcblk: probe of mmc2:0001 rejects match -19
[    1.164353] exynos-dp 145b0000.dp-controller: EDID data does not include any extensions.
[    1.173729] exynos-dp 145b0000.dp-controller: Link Training Clock Recovery success
[    1.175695] exynos-dp 145b0000.dp-controller: Link Training success!
[    1.241824] usb 1-1.1: new high-speed USB device number 3 using xhci-hcd
[    1.282317] exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok
[    1.282333] exynos-dp 145b0000.dp-controller: unable to config video
[    1.306078] Console: switching to colour frame buffer device 195x54
[    1.339302] exynos-drm exynos-drm: fb0:  frame buffer device
[    1.342018] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[    1.342191] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.343034] bus: 'usb': driver_probe_device: matched device 1-1.1 with driver usb
[    1.343214] bus: 'usb': really_probe: probing driver usb with device 1-1.1
[    1.351767] [drm] Initialized exynos 1.0.0 20110530 on minor 0
[    1.351924] driver: 'exynos-dp': driver_bound: bound to device '145b0000.dp-controller'
[    1.352113] bus: 'platform': really_probe: bound device 145b0000.dp-controller to driver exynos-dp
[    1.352373] initcall deferred_probe_initcall+0x0/0x88 returned 0 after 444139 usecs
[    1.352579] calling  genpd_poweroff_unused+0x0/0x10 @ 1
[    1.352731] initcall genpd_poweroff_unused+0x0/0x10 returned 0 after 17 usecs
[    1.352905] calling  gpio_keys_init+0x0/0x10 @ 1
[    1.353304] bus: 'platform': driver_probe_device: matched device gpio-keys with driver gpio-keys
[    1.353507] bus: 'platform': really_probe: probing driver gpio-keys with device gpio-keys
[    1.353969] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys/power[0]' - status (0)
[    1.354210] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys/lid-switch[0]' - status (0)
[    1.354489] gpio-143 (Power): gpiod_set_debounce: missing set() or set_debounce() operations
[    1.354806] gpio-161 (Lid): gpiod_set_debounce: missing set() or set_debounce() operations
[    1.362148] input: gpio-keys as /devices/platform/gpio-keys/input/input2
[    1.369136] driver: 'gpio-keys': driver_bound: bound to device 'gpio-keys'
[    1.375754] bus: 'platform': really_probe: bound device gpio-keys to driver gpio-keys
[    1.382625] bus: 'usb': driver_probe_device: matched device 1-1.1:1.0 with driver smsc95xx
[    1.389262] initcall gpio_keys_init+0x0/0x10 returned 0 after 35386 usecs
[    1.395759] bus: 'usb': really_probe: probing driver smsc95xx with device 1-1.1:1.0
[    1.402265] calling  rtc_hctosys+0x0/0xf4 @ 1
[    1.408772] smsc95xx v1.0.4
[    1.437322] max77686-rtc max77686-rtc: setting system clock to 2000-01-01 01:57:26 UTC (946691846)
[    1.443937] initcall rtc_hctosys+0x0/0xf4 returned 0 after 28140 usecs
[    1.451588] calling  of_fdt_raw_init+0x0/0x74 @ 1
[    1.458493] initcall of_fdt_raw_init+0x0/0x74 returned 0 after 434 usecs
[    1.461689] calling  clk_debug_init+0x0/0x138 @ 1
[    1.477872] initcall clk_debug_init+0x0/0x138 returned 0 after 12672 usecs
[    1.481044] calling  register_sk_filter_ops+0x0/0x8 @ 1
[    1.484255] initcall register_sk_filter_ops+0x0/0x8 returned 0 after 0 usecs
[    1.487492] calling  tcp_congestion_default+0x0/0xc @ 1
[    1.490691] initcall tcp_congestion_default+0x0/0xc returned 0 after 1 usecs
[    1.493899] calling  ip_auto_config+0x0/0x10b0 @ 1
[    1.514042] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-xhci-hcd.2.auto-1.1, smsc95xx USB 2.0 Ethernet, 94:eb:2c:00:00:a7
[    1.517308] driver: 'smsc95xx': driver_bound: bound to device '1-1.1:1.0'
[    1.520535] bus: 'usb': really_probe: bound device 1-1.1:1.0 to driver smsc95xx
[    1.523776] driver: 'usb': driver_bound: bound to device '1-1.1'
[    1.527000] bus: 'usb': really_probe: bound device 1-1.1 to driver usb
[    2.550550] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[    2.567181] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    4.068149] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
[    4.084229] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[    4.087043] Sending DHCP requests ., OK
[    4.126806] IP-Config: Got DHCP answer from 10.42.0.1, my address is 10.42.0.61
[    4.135375] IP-Config: Complete:
[    4.143386]      device=eth0, hwaddr=94:eb:2c:00:00:a7, ipaddr=10.42.0.61, mask=255.255.255.0, gw=10.42.0.1
[    4.151607]      host=10.42.0.61, domain=, nis-domain=(none)
[    4.159839]      bootserver=10.42.0.1, rootserver=10.42.0.1, rootpath=
[    4.160031]      nameserver0=10.42.0.1

[    4.176184] initcall ip_auto_config+0x0/0x10b0 returned 0 after 2616292 usecs
[    4.184459] calling  regulator_init_complete+0x0/0x48 @ 1
[    4.192736] TPS65090_RAILSDCDC1: disabling
[    4.200927] TPS65090_RAILSDCDC2: disabling
[    4.208995] TPS65090_RAILSDCDC3: disabling
[    4.217785] TPS65090_RAILSLDO1: disabling
[    4.225673] TPS65090_RAILSLDO2: disabling
[    4.233409] initcall regulator_init_complete+0x0/0x48 returned 0 after 39771 usecs
[    4.241321] calling  clk_disable_unused+0x0/0x138 @ 1
[    4.251036] initcall clk_disable_unused+0x0/0x138 returned 0 after 1869 usecs
[    4.253336] calling  alsa_sound_last_init+0x0/0x6c @ 1
[    4.255606] ALSA device list:
[    4.257859]   #0: Snow-I2S-MAX98095
[    4.260076] initcall alsa_sound_last_init+0x0/0x6c returned 0 after 4360 usecs
[    4.262337] calling  init_default_flow_dissectors+0x0/0x3c @ 1
[    4.264559] initcall init_default_flow_dissectors+0x0/0x3c returned 0 after 0 usecs
[    4.280283] VFS: Mounted root (nfs filesystem) on device 0:15.
[    4.283182] devtmpfs: mounted
[    4.285506] Freeing unused kernel memory: 428K (c0797000 - c0802000)
[    4.612617] random: systemd urandom read with 60 bits of entropy available
[    4.620773] systemd[1]: systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR)
[    4.624141] systemd[1]: Detected architecture 'arm'.
[    4.669694] systemd[1]: Failed to insert module 'autofs4'
[    4.675496] systemd[1]: Set hostname to <singularity>.
[    5.336213] systemd[1]: Cannot add dependency job for unit fstrim.timer, ignoring: Unit fstrim.timer failed to load: No such file or directory.
[    5.340944] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory.
[    5.347662] systemd[1]: Starting Forward Password Requests to Wall Directory Watch.
[    5.352548] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[    5.357117] systemd[1]: Starting Remote File Systems (Pre).
[    5.366583] systemd[1]: Reached target Remote File Systems (Pre).
[    5.371155] systemd[1]: Starting Encrypted Volumes.
[    5.380536] systemd[1]: Reached target Encrypted Volumes.
[    5.385193] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[    5.389753] systemd[1]: Starting Swap.
[    5.398864] systemd[1]: Reached target Swap.
[    5.403226] systemd[1]: Starting Root Slice.
[    5.412250] systemd[1]: Created slice Root Slice.
[    5.416473] systemd[1]: Starting Delayed Shutdown Socket.
[    5.425353] systemd[1]: Listening on Delayed Shutdown Socket.
[    5.429611] systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
[    5.439356] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[    5.443581] systemd[1]: Starting Journal Socket (/dev/log).
[    5.453105] systemd[1]: Listening on Journal Socket (/dev/log).
[    5.457315] systemd[1]: Starting udev Control Socket.
[    5.466584] systemd[1]: Listening on udev Control Socket.
[    5.470751] systemd[1]: Starting udev Kernel Socket.
[    5.478879] systemd[1]: Listening on udev Kernel Socket.
[    5.480820] systemd[1]: Starting User and Session Slice.
[    5.484988] systemd[1]: Created slice User and Session Slice.
[    5.486955] systemd[1]: Starting Journal Socket.
[    5.491019] systemd[1]: Listening on Journal Socket.
[    5.492991] systemd[1]: Starting System Slice.
[    5.497088] systemd[1]: Created slice System Slice.
[    5.503932] systemd[1]: Started Set Up Additional Binary Formats.
[    5.505876] systemd[1]: Mounted POSIX Message Queue File System.
[    5.507955] systemd[1]: Mounting Debug File System...
[    5.535382] systemd[1]: Starting Load Kernel Modules...
[    5.541341] systemd[1]: Starting Create list of required static device nodes for the current kernel...
[    5.546898] systemd[1]: Starting udev Coldplug all Devices...
[    5.553220] systemd[1]: Mounted Huge Pages File System.
[    5.555445] systemd[1]: Starting system-getty.slice.
[    5.560549] systemd[1]: Created slice system-getty.slice.
[    5.562837] systemd[1]: Starting Journal Service...
[    5.584166] systemd[1]: Started Journal Service.
[    5.863752] systemd-udevd[1824]: starting version 215
[    6.460842] random: nonblocking pool is initialized
[    7.142323] calling  mwifiex_init_module+0x0/0x10 [mwifiex] @ 2870
[    7.144261] initcall mwifiex_init_module+0x0/0x10 [mwifiex] returned 0 after 11 usecs
[    7.194574] calling  mwifiex_sdio_init_module+0x0/0x54 [mwifiex_sdio] @ 2870
[    7.198388] bus: 'sdio': driver_probe_device: matched device mmc2:0001:1 with driver mwifiex_sdio
[    7.203684] bus: 'sdio': really_probe: probing driver mwifiex_sdio with device mmc2:0001:1
[    7.228437] mwifiex: rx work enabled, cpus 2
[    7.253138] driver: 'mwifiex_sdio': driver_bound: bound to device 'mmc2:0001:1'
[    7.255160] bus: 'sdio': really_probe: bound device mmc2:0001:1 to driver mwifiex_sdio
[    7.265718] initcall mwifiex_sdio_init_module+0x0/0x54 [mwifiex_sdio] returned 0 after 65757 usecs
[    7.956437] mwifiex_sdio mmc2:0001:1: info: FW download over, size 458108 bytes
[    8.271818] mwifiex_sdio mmc2:0001:1: WLAN FW is active
[    8.667367] mwifiex_sdio mmc2:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (14.66.11.p151) 
[    8.672804] mwifiex_sdio mmc2:0001:1: driver_version = mwifiex 1.0 (14.66.11.p151) 
[   11.532582] systemd-journald[1590]: Received request to flush runtime journal from PID 1
[   18.478513] systemd-journald[1590]: Failed to read ACL on /var/log/journal/becefd5da725413ebc34ab1a301f3fc7/user-1001.journal, ignoring: Operation not supported

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

[-- Attachment #1: Type: text/plain, Size: 4626 bytes --]

On 10/22/2015 09:26 PM, Greg Kroah-Hartman wrote:
> On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote:
>> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>> <oops, sent too early...>
>>>
>>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>>>> But that's moot currently because Greg believes that the time spent
>>>> probing devices at boot time could be reduced enough so that the order
>>>> in which devices are probed becomes irrelevant. IME that would have to
>>>> be under 200ms so that the user doesn't notice and that's unicorn-far
>>>> from any bootlog I have ever seen.
>>>
>>> But as no one has actually produced a bootlog, how do you know that?
>>> Where exactly is your time being spent?  What driver is causing long
>>> delays?  Why is the long-delay-drivers not being done in their own
>>> thread?  And most importantly, why are you ignoring the work that people
>>> did back in 2008 to solve the issue on other hardware platforms?
>>>
>>>> Given that downstreams are already carrying as many hacks as they
>>>> could think of to speed total boot up, I think this is effectively
>>>> telling them to go away.
>>>
>>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
>>> solve-the-random-issue-i'm-having type patch by putting random calls in
>>> semi-random subsystems all over the kernel.
>>>
>>> And when I ask for real data, you respond with the fact that you aren't
>>> trying to speed up boot time here at all, so what am I supposed to think
>>
>> I also had the understanding that this patch series was about improving
>> boot time.  But I was kindly corrected that the behavior change was
>> getting the panel displaying stuff at an earlier point in the boot sequence,
>> _not_ completing the entire boot faster. 
>>
>> The claim for the current series, in patch 0 in v7 is:
>>
>>    With this series I get the kernel to output to the panel in 0.5s,
>>    instead of 2.8s.
>>
>> Just to get side-tracked, one other approach at ordering to reduce
>> deferrals reported a modest boot time reduction for four boards and a
>> very slight boot time increase for one other board.) The report of boot
>> times with that approach was in:
>>
>>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
>>
>> from Alexander Holler.
>>
>> I have not searched further to see if there is more data of boot time
>> reductions from any of the other attempts to change driver binding
>> order to move dependencies before use of a resource.  But whether
>> there is a performance improvement or not, there continues to be
>> a stream of developers creatively impacting the binding order for
>> their specific driver(s) or board.  So it seems that maybe there
>> is an underlying problem, or we don't have adequate documentation
>> explaining how to avoid a need to order bindings, or the
>> documentation exists and is not being read.
>>
>> I have been defaulting to the position that has been asserted by
>> the device tree maintainters, that probe deferrals work just fine
>> for at least the majority of cases (and is the message I have been
>> sharing in my conference presentations about device tree).  But I
>> suspect that there is at least a small minority of cases that are not
>> well served by probe deferral.  (Not to be read as an endorsement of
>> this specific patch series, just a generic observation.)
> 
> I agree, there might be some small numbers that this is a problem for,
> and if so, great, show us the boot logs where things are taking up all
> of the time, and we can work on resolving those issues.
> 
> But without hard numbers / details, this all is just random hand-waving,
> and I don't like making core kernel changes on that basis.  And no one
> else should ever want us to do that either.

Hi,

have found the board in which Stéphane had the original issue on
(exynos5250-snow), and I'm attaching the bootlog of
next-20151013+exynos_defconfig with initcall_debug and DEBUG in dd.c.

As can be seen, 145b0000.dp-controller is tried reasonably early (at
0.25s), but is deferred and only retried at 0.9s, with the display
finally coming up at 1.35s.

But I'm not sure what's the point in discussing this further if you have
already said that it's fine if downstreams have to change the probing
order by moving files around in the makefiles and by fiddling with
initcall levels.

To give a better understanding of what's going on here, I wasn't
involved in the bringup of this board, but was tasked with fixing this
issue in mainline so it doesn't have to be worked around in every product.

Regards,

Tomeu

> thanks,
> 
> greg k-h
> 


[-- Attachment #2: snow.txt --]
[-- Type: text/plain, Size: 132343 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.3.0-rc5-next-20151013-dirty (tomeu@cizrna) (gcc version 5.2.1 20150716 (Red Hat Cross 5.2.1-3) (GCC) ) #3491 SMP PREEMPT Fri Oct 23 11:17:16 CEST 2015
[    0.000000] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] Machine model: Google Snow
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] cma: Reserved 64 MiB at 0xbc000000
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Samsung CPU ID: 0x43520010
[    0.000000] On node 0 totalpages: 524288
[    0.000000] free_area_init_node: node 0, pgdat c083cc40, node_mem_map eeff7000
[    0.000000]   Normal zone: 1536 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 196608 pages, LIFO batch:31
[    0.000000]   HighMem zone: 327680 pages, LIFO batch:31
[    0.000000] PERCPU: Embedded 12 pages/cpu @eefa7000 s18880 r8192 d22080 u49152
[    0.000000] pcpu-alloc: s18880 r8192 d22080 u49152 alloc=12*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 522752
[    0.000000] Kernel command line: console=tty1 initcall_debug rw rootwait root=/dev/nfs nfsroot=10.42.0.1:/home/tomeu/nfsroot,vers=3 ip=dhcp ignore_loglevel log_buf_len=16M drm.debug=0x00 no_console_suspend
[    0.000000] log_buf_len: 16777216 bytes
[    0.000000] early log buf free: 129580(98%)
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 1988920K/2097152K available (5722K kernel code, 238K rwdata, 2016K rodata, 428K init, 315K bss, 42696K reserved, 65536K cma-reserved, 1245184K highmem)
[    0.000000] Virtual kernel memory layout:
                   vector  : 0xffff0000 - 0xffff1000   (   4 kB)
                   fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
                   vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
                   lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
                   pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
                   modules : 0xbf000000 - 0xbfe00000   (  14 MB)
                     .text : 0xc0008000 - 0xc0796ad4   (7739 kB)
                     .init : 0xc0797000 - 0xc0802000   ( 428 kB)
                     .data : 0xc0802000 - 0xc083dbc0   ( 239 kB)
                      .bss : 0xc0840000 - 0xc088ec90   ( 316 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] 	Build-time adjustment of leaf fanout to 32.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] GIC physical location is 0x10481000
[    0.000000] L2C: failed to init: -19
[    0.000000] Exynos5250: clock setup completed, armclk=1700000000
[    0.000000] Architected cp15 timer(s) running at 24.00MHz (virt).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[    0.000002] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
[    0.000009] Switching to timer-based delay loop, resolution 41ns
[    0.000170] Ignoring duplicate/late registration of read_current_timer delay
[    0.000178] clocksource: mct-frc: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[    0.000187] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
[    0.000484] Console: colour dummy device 80x30
[    0.000824] console [tty1] enabled
[    0.000838] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=120000)
[    0.000858] pid_max: default: 32768 minimum: 301
[    0.000937] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000950] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.001289] CPU: Testing write buffer coherency: ok
[    0.001421] CPU0: update cpu_capacity 1024
[    0.001433] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.001492] calling  cpu_suspend_alloc_sp+0x0/0x9c @ 1
[    0.001507] initcall cpu_suspend_alloc_sp+0x0/0x9c returned 0 after 0 usecs
[    0.001527] calling  init_static_idmap+0x0/0x114 @ 1
[    0.001545] Setting up static identity map for 0x40008280 - 0x400082d8
[    0.001564] initcall init_static_idmap+0x0/0x114 returned 0 after 0 usecs
[    0.001583] calling  exynos_mcpm_init+0x0/0x168 @ 1
[    0.001729] initcall exynos_mcpm_init+0x0/0x168 returned -19 after 0 usecs
[    0.001747] calling  spawn_ksoftirqd+0x0/0x34 @ 1
[    0.004936] initcall spawn_ksoftirqd+0x0/0x34 returned 0 after 4882 usecs
[    0.004955] calling  init_workqueues+0x0/0x3dc @ 1
[    0.019997] initcall init_workqueues+0x0/0x3dc returned 0 after 14648 usecs
[    0.020016] calling  migration_init+0x0/0x6c @ 1
[    0.020034] initcall migration_init+0x0/0x6c returned 0 after 0 usecs
[    0.020049] calling  check_cpu_stall_init+0x0/0x20 @ 1
[    0.020062] initcall check_cpu_stall_init+0x0/0x20 returned 0 after 0 usecs
[    0.020077] calling  rcu_spawn_gp_kthread+0x0/0x104 @ 1
[    0.020195] initcall rcu_spawn_gp_kthread+0x0/0x104 returned 0 after 0 usecs
[    0.020213] calling  cpu_stop_init+0x0/0xac @ 1
[    0.024982] initcall cpu_stop_init+0x0/0xac returned 0 after 4882 usecs
[    0.025000] calling  cci_init+0x0/0x18 @ 1
[    0.025080] initcall cci_init+0x0/0x18 returned -19 after 0 usecs
[    0.025098] calling  rand_initialize+0x0/0x2c @ 1
[    0.025214] initcall rand_initialize+0x0/0x2c returned 0 after 0 usecs
[    0.025232] calling  dummy_timer_register+0x0/0x48 @ 1
[    0.025247] initcall dummy_timer_register+0x0/0x48 returned 0 after 0 usecs
[    0.045065] CPU1: update cpu_capacity 1024
[    0.045069] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.045119] Brought up 2 CPUs
[    0.045146] SMP: Total of 2 processors activated (96.00 BogoMIPS).
[    0.045156] CPU: All CPU(s) started in SVC mode.
[    0.045767] devtmpfs: initialized
[    0.055547] calling  ipc_ns_init+0x0/0x3c @ 1
[    0.055566] initcall ipc_ns_init+0x0/0x3c returned 0 after 0 usecs
[    0.055580] calling  init_mmap_min_addr+0x0/0x20 @ 1
[    0.055592] initcall init_mmap_min_addr+0x0/0x20 returned 0 after 0 usecs
[    0.055608] calling  init_cpufreq_transition_notifier_list+0x0/0x24 @ 1
[    0.055625] initcall init_cpufreq_transition_notifier_list+0x0/0x24 returned 0 after 0 usecs
[    0.055647] calling  net_ns_init+0x0/0x14c @ 1
[    0.055754] initcall net_ns_init+0x0/0x14c returned 0 after 0 usecs
[    0.055833] calling  vfp_init+0x0/0x1b8 @ 1
[    0.055847] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
[    0.055871] initcall vfp_init+0x0/0x1b8 returned 0 after 0 usecs
[    0.055885] calling  ptrace_break_init+0x0/0x2c @ 1
[    0.055898] initcall ptrace_break_init+0x0/0x2c returned 0 after 0 usecs
[    0.055913] calling  register_cpufreq_notifier+0x0/0x10 @ 1
[    0.055926] initcall register_cpufreq_notifier+0x0/0x10 returned 0 after 0 usecs
[    0.055945] calling  v6_userpage_init+0x0/0x8 @ 1
[    0.055957] initcall v6_userpage_init+0x0/0x8 returned 0 after 0 usecs
[    0.055973] calling  exynos4_pm_init_power_domain+0x0/0x2e0 @ 1
[    0.056176] initcall exynos4_pm_init_power_domain+0x0/0x2e0 returned 0 after 0 usecs
[    0.056197] calling  cpu_hotplug_pm_sync_init+0x0/0x18 @ 1
[    0.056210] initcall cpu_hotplug_pm_sync_init+0x0/0x18 returned 0 after 0 usecs
[    0.056230] calling  alloc_frozen_cpus+0x0/0x8 @ 1
[    0.056241] initcall alloc_frozen_cpus+0x0/0x8 returned 0 after 0 usecs
[    0.056257] calling  wq_sysfs_init+0x0/0x30 @ 1
[    0.056444] initcall wq_sysfs_init+0x0/0x30 returned 0 after 0 usecs
[    0.056462] calling  ksysfs_init+0x0/0xa4 @ 1
[    0.056494] initcall ksysfs_init+0x0/0xa4 returned 0 after 0 usecs
[    0.056511] calling  pm_init+0x0/0x78 @ 1
[    0.056565] initcall pm_init+0x0/0x78 returned 0 after 0 usecs
[    0.056579] calling  init_jiffies_clocksource+0x0/0x14 @ 1
[    0.056592] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302231375000 ns
[    0.056610] initcall init_jiffies_clocksource+0x0/0x14 returned 0 after 0 usecs
[    0.056628] calling  cgroup_wq_init+0x0/0x80 @ 1
[    0.056665] initcall cgroup_wq_init+0x0/0x80 returned 0 after 0 usecs
[    0.056680] calling  cpu_pm_init+0x0/0x18 @ 1
[    0.056692] initcall cpu_pm_init+0x0/0x18 returned 0 after 0 usecs
[    0.056707] calling  init_zero_pfn+0x0/0x40 @ 1
[    0.056718] initcall init_zero_pfn+0x0/0x40 returned 0 after 0 usecs
[    0.056734] calling  cma_init_reserved_areas+0x0/0x1d4 @ 1
[    0.057256] initcall cma_init_reserved_areas+0x0/0x1d4 returned 0 after 0 usecs
[    0.057278] calling  fsnotify_init+0x0/0x24 @ 1
[    0.057294] initcall fsnotify_init+0x0/0x24 returned 0 after 0 usecs
[    0.057310] calling  filelock_init+0x0/0xc4 @ 1
[    0.057335] initcall filelock_init+0x0/0xc4 returned 0 after 0 usecs
[    0.057351] calling  init_script_binfmt+0x0/0x1c @ 1
[    0.057364] initcall init_script_binfmt+0x0/0x1c returned 0 after 0 usecs
[    0.057379] calling  init_elf_binfmt+0x0/0x1c @ 1
[    0.057391] initcall init_elf_binfmt+0x0/0x1c returned 0 after 0 usecs
[    0.057407] calling  configfs_init+0x0/0xb0 @ 1
[    0.057437] initcall configfs_init+0x0/0xb0 returned 0 after 0 usecs
[    0.057451] calling  debugfs_init+0x0/0x68 @ 1
[    0.057467] initcall debugfs_init+0x0/0x68 returned 0 after 0 usecs
[    0.057480] calling  securityfs_init+0x0/0x58 @ 1
[    0.057495] initcall securityfs_init+0x0/0x58 returned 0 after 0 usecs
[    0.057509] calling  prandom_init+0x0/0xe4 @ 1
[    0.057521] initcall prandom_init+0x0/0xe4 returned 0 after 0 usecs
[    0.057535] calling  cci_platform_init+0x0/0x8 @ 1
[    0.057546] initcall cci_platform_init+0x0/0x8 returned 0 after 0 usecs
[    0.057560] calling  pinctrl_init+0x0/0xd4 @ 1
[    0.057569] pinctrl core: initialized pinctrl subsystem
[    0.057622] initcall pinctrl_init+0x0/0xd4 returned 0 after 0 usecs
[    0.057638] calling  regulator_init+0x0/0xa4 @ 1
[    0.057836] bus: 'platform': driver_probe_device: matched device reg-dummy with driver reg-dummy
[    0.057855] bus: 'platform': really_probe: probing driver reg-dummy with device reg-dummy
[    0.058019] driver: 'reg-dummy': driver_bound: bound to device 'reg-dummy'
[    0.058033] bus: 'platform': really_probe: bound device reg-dummy to driver reg-dummy
[    0.058097] initcall regulator_init+0x0/0xa4 returned 0 after 0 usecs
[    0.058114] calling  cpufreq_core_init+0x0/0x50 @ 1
[    0.058126] initcall cpufreq_core_init+0x0/0x50 returned 0 after 0 usecs
[    0.058140] calling  cpuidle_init+0x0/0x58 @ 1
[    0.058163] initcall cpuidle_init+0x0/0x58 returned 0 after 0 usecs
[    0.058177] calling  cpuidle_coupled_init+0x0/0xc @ 1
[    0.058190] initcall cpuidle_coupled_init+0x0/0xc returned 0 after 0 usecs
[    0.058207] calling  exynos_audss_clk_init+0x0/0x10 @ 1
[    0.058265] initcall exynos_audss_clk_init+0x0/0x10 returned 0 after 0 usecs
[    0.058282] calling  sock_init+0x0/0x94 @ 1
[    0.058334] initcall sock_init+0x0/0x94 returned 0 after 0 usecs
[    0.058351] calling  net_inuse_init+0x0/0x24 @ 1
[    0.058365] initcall net_inuse_init+0x0/0x24 returned 0 after 0 usecs
[    0.058379] calling  netlink_proto_init+0x0/0x148 @ 1
[    0.058490] NET: Registered protocol family 16
[    0.058519] initcall netlink_proto_init+0x0/0x148 returned 0 after 0 usecs
[    0.058604] calling  atomic_pool_init+0x0/0x168 @ 1
[    0.059145] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.059160] initcall atomic_pool_init+0x0/0x168 returned 0 after 0 usecs
[    0.059177] calling  exynos_pmu_init+0x0/0x10 @ 1
[    0.059247] initcall exynos_pmu_init+0x0/0x10 returned 0 after 0 usecs
[    0.059265] calling  bdi_class_init+0x0/0x5c @ 1
[    0.059317] initcall bdi_class_init+0x0/0x5c returned 0 after 0 usecs
[    0.059333] calling  mm_sysfs_init+0x0/0x38 @ 1
[    0.059349] initcall mm_sysfs_init+0x0/0x38 returned 0 after 0 usecs
[    0.059364] calling  kobject_uevent_init+0x0/0xc @ 1
[    0.059383] initcall kobject_uevent_init+0x0/0xc returned 0 after 0 usecs
[    0.059398] calling  samsung_pinctrl_drv_register+0x0/0x24 @ 1
[    0.059457] initcall samsung_pinctrl_drv_register+0x0/0x24 returned 0 after 0 usecs
[    0.059477] calling  exynos5440_pinctrl_drv_register+0x0/0x10 @ 1
[    0.059533] initcall exynos5440_pinctrl_drv_register+0x0/0x10 returned 0 after 0 usecs
[    0.059553] calling  lcd_class_init+0x0/0x58 @ 1
[    0.059601] initcall lcd_class_init+0x0/0x58 returned 0 after 0 usecs
[    0.059616] calling  backlight_class_init+0x0/0xa4 @ 1
[    0.059661] initcall backlight_class_init+0x0/0xa4 returned 0 after 0 usecs
[    0.059677] calling  amba_init+0x0/0xc @ 1
[    0.059741] initcall amba_init+0x0/0xc returned 0 after 0 usecs
[    0.059757] calling  tty_class_init+0x0/0x40 @ 1
[    0.059800] initcall tty_class_init+0x0/0x40 returned 0 after 0 usecs
[    0.059817] calling  vtconsole_class_init+0x0/0xec @ 1
[    0.059947] initcall vtconsole_class_init+0x0/0xec returned 0 after 0 usecs
[    0.059965] calling  mipi_dsi_bus_init+0x0/0xc @ 1
[    0.060052] initcall mipi_dsi_bus_init+0x0/0xc returned 0 after 4882 usecs
[    0.060070] calling  wakeup_sources_debugfs_init+0x0/0x38 @ 1
[    0.060104] initcall wakeup_sources_debugfs_init+0x0/0x38 returned 0 after 0 usecs
[    0.060123] calling  regmap_initcall+0x0/0x10 @ 1
[    0.060141] initcall regmap_initcall+0x0/0x10 returned 0 after 0 usecs
[    0.060157] calling  sram_init+0x0/0x10 @ 1
[    0.060218] initcall sram_init+0x0/0x10 returned 0 after 0 usecs
[    0.060235] calling  syscon_init+0x0/0x10 @ 1
[    0.060291] initcall syscon_init+0x0/0x10 returned 0 after 0 usecs
[    0.060307] calling  spi_init+0x0/0x94 @ 1
[    0.060403] initcall spi_init+0x0/0x94 returned 0 after 0 usecs
[    0.060418] calling  i2c_init+0x0/0xb8 @ 1
[    0.060538] initcall i2c_init+0x0/0xb8 returned 0 after 0 usecs
[    0.060553] calling  init_ladder+0x0/0xc @ 1
[    0.075090] cpuidle: using governor ladder
[    0.075103] initcall init_ladder+0x0/0xc returned 0 after 14648 usecs
[    0.075116] calling  init_menu+0x0/0xc @ 1
[    0.095118] cpuidle: using governor menu
[    0.095131] initcall init_menu+0x0/0xc returned 0 after 19531 usecs
[    0.095207] calling  gate_vma_init+0x0/0x24 @ 1
[    0.095219] initcall gate_vma_init+0x0/0x24 returned 0 after 0 usecs
[    0.095233] calling  customize_machine+0x0/0x40 @ 1
[    0.097232] bus: 'platform': driver_probe_device: matched device 2020000.sysram with driver sram
[    0.097251] bus: 'platform': really_probe: probing driver sram with device 2020000.sysram
[    0.097318] driver: 'sram': driver_bound: bound to device '2020000.sysram'
[    0.097332] bus: 'platform': really_probe: bound device 2020000.sysram to driver sram
[    0.097885] bus: 'platform': driver_probe_device: matched device 3810000.audss-clock-controller with driver exynos-audss-clk
[    0.097903] bus: 'platform': really_probe: probing driver exynos-audss-clk with device 3810000.audss-clock-controller
[    0.098183] exynos-audss-clk 3810000.audss-clock-controller: setup completed
[    0.098197] driver: 'exynos-audss-clk': driver_bound: bound to device '3810000.audss-clock-controller'
[    0.098213] bus: 'platform': really_probe: bound device 3810000.audss-clock-controller to driver exynos-audss-clk
[    0.098911] bus: 'platform': driver_probe_device: matched device 11400000.pinctrl with driver samsung-pinctrl
[    0.098929] bus: 'platform': really_probe: probing driver samsung-pinctrl with device 11400000.pinctrl
[    0.099063] gpiochip_add: registered GPIOs 0 to 7 on device: gpa0
[    0.099077] gpiochip_add: registered GPIOs 8 to 13 on device: gpa1
[    0.099090] gpiochip_add: registered GPIOs 14 to 21 on device: gpa2
[    0.099102] gpiochip_add: registered GPIOs 22 to 26 on device: gpb0
[    0.099114] gpiochip_add: registered GPIOs 27 to 31 on device: gpb1
[    0.099127] gpiochip_add: registered GPIOs 32 to 35 on device: gpb2
[    0.099138] gpiochip_add: registered GPIOs 36 to 39 on device: gpb3
[    0.099150] gpiochip_add: registered GPIOs 40 to 46 on device: gpc0
[    0.099162] gpiochip_add: registered GPIOs 47 to 50 on device: gpc1
[    0.099177] gpiochip_add: registered GPIOs 51 to 57 on device: gpc2
[    0.099188] gpiochip_add: registered GPIOs 58 to 64 on device: gpc3
[    0.099201] gpiochip_add: registered GPIOs 65 to 68 on device: gpd0
[    0.099213] gpiochip_add: registered GPIOs 69 to 76 on device: gpd1
[    0.099225] gpiochip_add: registered GPIOs 77 to 83 on device: gpc4
[    0.099237] gpiochip_add: registered GPIOs 84 to 89 on device: gpy0
[    0.099249] gpiochip_add: registered GPIOs 90 to 93 on device: gpy1
[    0.099261] gpiochip_add: registered GPIOs 94 to 99 on device: gpy2
[    0.099274] gpiochip_add: registered GPIOs 100 to 107 on device: gpy3
[    0.099286] gpiochip_add: registered GPIOs 108 to 115 on device: gpy4
[    0.099298] gpiochip_add: registered GPIOs 116 to 123 on device: gpy5
[    0.099311] gpiochip_add: registered GPIOs 124 to 131 on device: gpy6
[    0.099323] gpiochip_add: registered GPIOs 132 to 139 on device: gpx0
[    0.099336] gpiochip_add: registered GPIOs 140 to 147 on device: gpx1
[    0.099348] gpiochip_add: registered GPIOs 148 to 155 on device: gpx2
[    0.099360] gpiochip_add: registered GPIOs 156 to 163 on device: gpx3
[    0.100001] driver: 'samsung-pinctrl': driver_bound: bound to device '11400000.pinctrl'
[    0.100019] bus: 'platform': really_probe: bound device 11400000.pinctrl to driver samsung-pinctrl
[    0.100207] bus: 'platform': driver_probe_device: matched device 13400000.pinctrl with driver samsung-pinctrl
[    0.100225] bus: 'platform': really_probe: probing driver samsung-pinctrl with device 13400000.pinctrl
[    0.100290] gpiochip_add: registered GPIOs 164 to 171 on device: gpe0
[    0.100304] gpiochip_add: registered GPIOs 172 to 173 on device: gpe1
[    0.100317] gpiochip_add: registered GPIOs 174 to 177 on device: gpf0
[    0.100330] gpiochip_add: registered GPIOs 178 to 181 on device: gpf1
[    0.100342] gpiochip_add: registered GPIOs 182 to 189 on device: gpg0
[    0.100355] gpiochip_add: registered GPIOs 190 to 197 on device: gpg1
[    0.100367] gpiochip_add: registered GPIOs 198 to 199 on device: gpg2
[    0.100379] gpiochip_add: registered GPIOs 200 to 203 on device: gph0
[    0.100392] gpiochip_add: registered GPIOs 204 to 211 on device: gph1
[    0.100580] driver: 'samsung-pinctrl': driver_bound: bound to device '13400000.pinctrl'
[    0.100597] bus: 'platform': really_probe: bound device 13400000.pinctrl to driver samsung-pinctrl
[    0.100751] bus: 'platform': driver_probe_device: matched device 10d10000.pinctrl with driver samsung-pinctrl
[    0.100769] bus: 'platform': really_probe: probing driver samsung-pinctrl with device 10d10000.pinctrl
[    0.100825] gpiochip_add: registered GPIOs 212 to 219 on device: gpv0
[    0.100838] gpiochip_add: registered GPIOs 220 to 227 on device: gpv1
[    0.100851] gpiochip_add: registered GPIOs 228 to 235 on device: gpv2
[    0.100863] gpiochip_add: registered GPIOs 236 to 243 on device: gpv3
[    0.100876] gpiochip_add: registered GPIOs 244 to 245 on device: gpv4
[    0.101006] driver: 'samsung-pinctrl': driver_bound: bound to device '10d10000.pinctrl'
[    0.101023] bus: 'platform': really_probe: bound device 10d10000.pinctrl to driver samsung-pinctrl
[    0.101175] bus: 'platform': driver_probe_device: matched device 3860000.pinctrl with driver samsung-pinctrl
[    0.101192] bus: 'platform': really_probe: probing driver samsung-pinctrl with device 3860000.pinctrl
[    0.101237] gpiochip_add: registered GPIOs 246 to 252 on device: gpz
[    0.101330] driver: 'samsung-pinctrl': driver_bound: bound to device '3860000.pinctrl'
[    0.101347] bus: 'platform': really_probe: bound device 3860000.pinctrl to driver samsung-pinctrl
[    0.101472] bus: 'platform': driver_probe_device: matched device 10040000.system-controller with driver exynos-pmu
[    0.101490] bus: 'platform': really_probe: probing driver exynos-pmu with device 10040000.system-controller
[    0.101531] driver: 'exynos-pmu': driver_bound: bound to device '10040000.system-controller'
[    0.101547] bus: 'platform': really_probe: bound device 10040000.system-controller to driver exynos-pmu
[    0.109998] initcall customize_machine+0x0/0x40 returned 0 after 9765 usecs
[    0.110020] calling  vdso_init+0x0/0x1a4 @ 1
[    0.110049] initcall vdso_init+0x0/0x1a4 returned 0 after 0 usecs
[    0.110064] calling  exceptions_init+0x0/0x9c @ 1
[    0.110077] initcall exceptions_init+0x0/0x9c returned 0 after 0 usecs
[    0.110093] calling  s3c_arch_init+0x0/0x40 @ 1
[    0.110106] initcall s3c_arch_init+0x0/0x40 returned 0 after 0 usecs
[    0.110121] calling  dma_bus_init+0x0/0xa8 @ 1
[    0.110212] initcall dma_bus_init+0x0/0xa8 returned 0 after 0 usecs
[    0.110230] calling  dma_channel_table_init+0x0/0xf0 @ 1
[    0.110255] initcall dma_channel_table_init+0x0/0xf0 returned 0 after 0 usecs
[    0.110337] calling  topology_init+0x0/0x74 @ 1
[    0.110517] initcall topology_init+0x0/0x74 returned 0 after 0 usecs
[    0.110535] calling  uid_cache_init+0x0/0xa4 @ 1
[    0.110550] initcall uid_cache_init+0x0/0xa4 returned 0 after 0 usecs
[    0.110567] calling  param_sysfs_init+0x0/0x1d8 @ 1
[    0.119328] initcall param_sysfs_init+0x0/0x1d8 returned 0 after 4882 usecs
[    0.119354] calling  pm_sysrq_init+0x0/0x1c @ 1
[    0.130217] initcall pm_sysrq_init+0x0/0x1c returned 0 after 14648 usecs
[    0.130237] calling  hung_task_init+0x0/0x58 @ 1
[    0.130296] initcall hung_task_init+0x0/0x58 returned 0 after 0 usecs
[    0.130312] calling  default_bdi_init+0x0/0x58 @ 1
[    0.130493] initcall default_bdi_init+0x0/0x58 returned 0 after 0 usecs
[    0.130510] calling  percpu_enable_async+0x0/0x18 @ 1
[    0.130522] initcall percpu_enable_async+0x0/0x18 returned 0 after 0 usecs
[    0.130539] calling  init_reserve_notifier+0x0/0x8 @ 1
[    0.130552] initcall init_reserve_notifier+0x0/0x8 returned 0 after 0 usecs
[    0.130573] calling  init_admin_reserve+0x0/0x30 @ 1
[    0.130586] initcall init_admin_reserve+0x0/0x30 returned 0 after 0 usecs
[    0.130602] calling  init_user_reserve+0x0/0x30 @ 1
[    0.130614] initcall init_user_reserve+0x0/0x30 returned 0 after 0 usecs
[    0.130628] calling  crypto_wq_init+0x0/0x44 @ 1
[    0.130696] initcall crypto_wq_init+0x0/0x44 returned 0 after 0 usecs
[    0.130711] calling  cryptomgr_init+0x0/0xc @ 1
[    0.130722] initcall cryptomgr_init+0x0/0xc returned 0 after 0 usecs
[    0.130735] calling  init_bio+0x0/0xc0 @ 1
[    0.130824] initcall init_bio+0x0/0xc0 returned 0 after 0 usecs
[    0.130839] calling  blk_settings_init+0x0/0x38 @ 1
[    0.130850] initcall blk_settings_init+0x0/0x38 returned 0 after 0 usecs
[    0.130863] calling  blk_ioc_init+0x0/0x40 @ 1
[    0.130877] initcall blk_ioc_init+0x0/0x40 returned 0 after 0 usecs
[    0.130890] calling  blk_softirq_init+0x0/0x80 @ 1
[    0.130903] initcall blk_softirq_init+0x0/0x80 returned 0 after 0 usecs
[    0.130917] calling  blk_iopoll_setup+0x0/0x80 @ 1
[    0.130928] initcall blk_iopoll_setup+0x0/0x80 returned 0 after 0 usecs
[    0.130941] calling  blk_mq_init+0x0/0x1c @ 1
[    0.130953] initcall blk_mq_init+0x0/0x1c returned 0 after 0 usecs
[    0.130967] calling  genhd_device_init+0x0/0x80 @ 1
[    0.131085] initcall genhd_device_init+0x0/0x80 returned 0 after 0 usecs
[    0.131102] calling  gpiolib_debugfs_init+0x0/0x38 @ 1
[    0.131123] initcall gpiolib_debugfs_init+0x0/0x38 returned 0 after 0 usecs
[    0.131138] calling  pwm_debugfs_init+0x0/0x38 @ 1
[    0.131153] initcall pwm_debugfs_init+0x0/0x38 returned 0 after 0 usecs
[    0.131168] calling  pwm_sysfs_init+0x0/0x14 @ 1
[    0.131215] initcall pwm_sysfs_init+0x0/0x14 returned 0 after 0 usecs
[    0.131230] calling  fbmem_init+0x0/0xb4 @ 1
[    0.131285] initcall fbmem_init+0x0/0xb4 returned 0 after 0 usecs
[    0.131302] calling  regulator_fixed_voltage_init+0x0/0x10 @ 1
[    0.131427] bus: 'platform': driver_probe_device: matched device vbat-fixed-regulator with driver reg-fixed-voltage
[    0.131445] bus: 'platform': really_probe: probing driver reg-fixed-voltage with device vbat-fixed-regulator
[    0.131498] of_get_named_gpiod_flags: can't parse 'gpio' property of node '/vbat-fixed-regulator[0]'
[    0.131664] driver: 'reg-fixed-voltage': driver_bound: bound to device 'vbat-fixed-regulator'
[    0.131682] bus: 'platform': really_probe: bound device vbat-fixed-regulator to driver reg-fixed-voltage
[    0.131704] bus: 'platform': driver_probe_device: matched device regulator-usb3 with driver reg-fixed-voltage
[    0.131722] bus: 'platform': really_probe: probing driver reg-fixed-voltage with device regulator-usb3
[    0.131832] of_get_named_gpiod_flags: parsed 'gpio' property of node '/regulator-usb3[0]' - status (0)
[    0.132003] driver: 'reg-fixed-voltage': driver_bound: bound to device 'regulator-usb3'
[    0.132021] bus: 'platform': really_probe: bound device regulator-usb3 to driver reg-fixed-voltage
[    0.132089] initcall regulator_fixed_voltage_init+0x0/0x10 returned 0 after 0 usecs
[    0.132109] calling  gpio_regulator_init+0x0/0x10 @ 1
[    0.132241] initcall gpio_regulator_init+0x0/0x10 returned 0 after 0 usecs
[    0.132258] calling  max14577_regulator_init+0x0/0x10 @ 1
[    0.132344] initcall max14577_regulator_init+0x0/0x10 returned 0 after 0 usecs
[    0.132364] calling  max8997_pmic_init+0x0/0x10 @ 1
[    0.132445] initcall max8997_pmic_init+0x0/0x10 returned 0 after 0 usecs
[    0.132461] calling  max77686_pmic_init+0x0/0x10 @ 1
[    0.132548] initcall max77686_pmic_init+0x0/0x10 returned 0 after 0 usecs
[    0.132564] calling  max77693_pmic_init+0x0/0x10 @ 1
[    0.132650] initcall max77693_pmic_init+0x0/0x10 returned 0 after 0 usecs
[    0.132666] calling  s2mps11_pmic_init+0x0/0x10 @ 1
[    0.132751] initcall s2mps11_pmic_init+0x0/0x10 returned 0 after 0 usecs
[    0.132767] calling  s5m8767_pmic_init+0x0/0x10 @ 1
[    0.132850] initcall s5m8767_pmic_init+0x0/0x10 returned 0 after 0 usecs
[    0.132866] calling  tps65090_regulator_init+0x0/0x10 @ 1
[    0.132952] initcall tps65090_regulator_init+0x0/0x10 returned 0 after 0 usecs
[    0.132972] calling  misc_init+0x0/0xe0 @ 1
[    0.133025] initcall misc_init+0x0/0xe0 returned 0 after 0 usecs
[    0.133040] calling  tpm_init+0x0/0x8c @ 1
[    0.133086] initcall tpm_init+0x0/0x8c returned 0 after 0 usecs
[    0.133104] calling  max14577_i2c_init+0x0/0x10 @ 1
[    0.133160] initcall max14577_i2c_init+0x0/0x10 returned 0 after 0 usecs
[    0.133177] calling  max77686_i2c_init+0x0/0x10 @ 1
[    0.133232] initcall max77686_i2c_init+0x0/0x10 returned 0 after 0 usecs
[    0.133249] calling  max77693_i2c_init+0x0/0x10 @ 1
[    0.133303] initcall max77693_i2c_init+0x0/0x10 returned 0 after 0 usecs
[    0.133320] calling  max8997_i2c_init+0x0/0x10 @ 1
[    0.133375] initcall max8997_i2c_init+0x0/0x10 returned 0 after 0 usecs
[    0.133392] calling  tps65090_init+0x0/0x10 @ 1
[    0.133447] initcall tps65090_init+0x0/0x10 returned 0 after 0 usecs
[    0.133463] calling  sec_pmic_init+0x0/0x10 @ 1
[    0.133518] initcall sec_pmic_init+0x0/0x10 returned 0 after 0 usecs
[    0.133534] calling  dma_buf_init+0x0/0x84 @ 1
[    0.133555] initcall dma_buf_init+0x0/0x84 returned 0 after 0 usecs
[    0.133571] calling  init_scsi+0x0/0x8c @ 1
[    0.133795] SCSI subsystem initialized
[    0.133810] initcall init_scsi+0x0/0x8c returned 0 after 0 usecs
[    0.133826] calling  phy_init+0x0/0x3c @ 1
[    0.134005] initcall phy_init+0x0/0x3c returned 0 after 0 usecs
[    0.134022] calling  usb_init+0x0/0x17c @ 1
[    0.134159] usbcore: registered new interface driver usbfs
[    0.134230] usbcore: registered new interface driver hub
[    0.134308] usbcore: registered new device driver usb
[    0.134322] initcall usb_init+0x0/0x17c returned 0 after 0 usecs
[    0.134339] calling  usb_udc_init+0x0/0x58 @ 1
[    0.134384] initcall usb_udc_init+0x0/0x58 returned 0 after 0 usecs
[    0.134398] calling  serio_init+0x0/0x30 @ 1
[    0.134459] initcall serio_init+0x0/0x30 returned 0 after 0 usecs
[    0.134473] calling  input_init+0x0/0x11c @ 1
[    0.134525] initcall input_init+0x0/0x11c returned 0 after 0 usecs
[    0.134539] calling  rtc_init+0x0/0x58 @ 1
[    0.134584] initcall rtc_init+0x0/0x58 returned 0 after 0 usecs
[    0.134598] calling  i2c_gpio_init+0x0/0x34 @ 1
[    0.134740] initcall i2c_gpio_init+0x0/0x34 returned 0 after 0 usecs
[    0.134754] calling  i2c_adap_s3c_init+0x0/0x10 @ 1
[    0.134821] bus: 'platform': driver_probe_device: matched device 12c60000.i2c with driver s3c-i2c
[    0.134838] bus: 'platform': really_probe: probing driver s3c-i2c with device 12c60000.i2c
[    0.134973] s3c-i2c 12c60000.i2c: slave address 0x00
[    0.134988] s3c-i2c 12c60000.i2c: bus frequency set to 378 KHz
[    0.135315] bus: 'i2c': driver_probe_device: matched device 0-0009 with driver max77686
[    0.135335] bus: 'i2c': really_probe: probing driver max77686 with device 0-0009
[    0.135750] bus: 'i2c': driver_probe_device: matched device 0-0006 with driver dummy
[    0.135769] bus: 'i2c': really_probe: probing driver dummy with device 0-0006
[    0.135796] driver: 'dummy': driver_bound: bound to device '0-0006'
[    0.135808] bus: 'i2c': really_probe: bound device 0-0006 to driver dummy
[    0.136613] bus: 'platform': driver_probe_device: matched device max77686-pmic with driver max77686-pmic
[    0.136631] bus: 'platform': really_probe: probing driver max77686-pmic with device max77686-pmic
[    0.155437] of_get_named_gpiod_flags: can't parse 'maxim,ena-gpios' property of node '/i2c@12C60000/max77686@09/voltage-regulators/BUCK8[0]'
[    0.156487] driver: 'max77686-pmic': driver_bound: bound to device 'max77686-pmic'
[    0.156505] bus: 'platform': really_probe: bound device max77686-pmic to driver max77686-pmic
[    0.156702] driver: 'max77686': driver_bound: bound to device '0-0009'
[    0.156715] bus: 'i2c': really_probe: bound device 0-0009 to driver max77686
[    0.156737] s3c-i2c 12c60000.i2c: i2c-0: S3C I2C adapter
[    0.156748] driver: 's3c-i2c': driver_bound: bound to device '12c60000.i2c'
[    0.156760] bus: 'platform': really_probe: bound device 12c60000.i2c to driver s3c-i2c
[    0.156781] bus: 'platform': driver_probe_device: matched device 12c70000.i2c with driver s3c-i2c
[    0.156797] bus: 'platform': really_probe: probing driver s3c-i2c with device 12c70000.i2c
[    0.156922] s3c-i2c 12c70000.i2c: slave address 0x00
[    0.156937] s3c-i2c 12c70000.i2c: bus frequency set to 378 KHz
[    0.157205] s3c-i2c 12c70000.i2c: i2c-1: S3C I2C adapter
[    0.157218] driver: 's3c-i2c': driver_bound: bound to device '12c70000.i2c'
[    0.157231] bus: 'platform': really_probe: bound device 12c70000.i2c to driver s3c-i2c
[    0.157251] bus: 'platform': driver_probe_device: matched device 12c80000.i2c with driver s3c-i2c
[    0.157267] bus: 'platform': really_probe: probing driver s3c-i2c with device 12c80000.i2c
[    0.157352] s3c-i2c 12c80000.i2c: slave address 0x00
[    0.157366] s3c-i2c 12c80000.i2c: bus frequency set to 65 KHz
[    0.157617] s3c-i2c 12c80000.i2c: i2c-2: S3C I2C adapter
[    0.157629] driver: 's3c-i2c': driver_bound: bound to device '12c80000.i2c'
[    0.157641] bus: 'platform': really_probe: bound device 12c80000.i2c to driver s3c-i2c
[    0.157660] bus: 'platform': driver_probe_device: matched device 12c90000.i2c with driver s3c-i2c
[    0.157676] bus: 'platform': really_probe: probing driver s3c-i2c with device 12c90000.i2c
[    0.157763] s3c-i2c 12c90000.i2c: slave address 0x00
[    0.157776] s3c-i2c 12c90000.i2c: bus frequency set to 65 KHz
[    0.157929] s3c-i2c 12c90000.i2c: i2c-3: S3C I2C adapter
[    0.157941] driver: 's3c-i2c': driver_bound: bound to device '12c90000.i2c'
[    0.157953] bus: 'platform': really_probe: bound device 12c90000.i2c to driver s3c-i2c
[    0.157972] bus: 'platform': driver_probe_device: matched device 12ca0000.i2c with driver s3c-i2c
[    0.157988] bus: 'platform': really_probe: probing driver s3c-i2c with device 12ca0000.i2c
[    0.158063] s3c-i2c 12ca0000.i2c: slave address 0x00
[    0.158077] s3c-i2c 12ca0000.i2c: bus frequency set to 65 KHz
[    0.158230] s3c-i2c 12ca0000.i2c: i2c-4: S3C I2C adapter
[    0.158241] driver: 's3c-i2c': driver_bound: bound to device '12ca0000.i2c'
[    0.158253] bus: 'platform': really_probe: bound device 12ca0000.i2c to driver s3c-i2c
[    0.158272] bus: 'platform': driver_probe_device: matched device 12cb0000.i2c with driver s3c-i2c
[    0.158289] bus: 'platform': really_probe: probing driver s3c-i2c with device 12cb0000.i2c
[    0.158365] s3c-i2c 12cb0000.i2c: slave address 0x00
[    0.158379] s3c-i2c 12cb0000.i2c: bus frequency set to 65 KHz
[    0.158538] s3c-i2c 12cb0000.i2c: i2c-5: S3C I2C adapter
[    0.158550] driver: 's3c-i2c': driver_bound: bound to device '12cb0000.i2c'
[    0.158562] bus: 'platform': really_probe: bound device 12cb0000.i2c to driver s3c-i2c
[    0.158581] bus: 'platform': driver_probe_device: matched device 12cd0000.i2c with driver s3c-i2c
[    0.158598] bus: 'platform': really_probe: probing driver s3c-i2c with device 12cd0000.i2c
[    0.158676] s3c-i2c 12cd0000.i2c: slave address 0x00
[    0.158690] s3c-i2c 12cd0000.i2c: bus frequency set to 65 KHz
[    0.159023] s3c-i2c 12cd0000.i2c: i2c-7: S3C I2C adapter
[    0.159035] driver: 's3c-i2c': driver_bound: bound to device '12cd0000.i2c'
[    0.159046] bus: 'platform': really_probe: bound device 12cd0000.i2c to driver s3c-i2c
[    0.159066] bus: 'platform': driver_probe_device: matched device 12ce0000.i2c with driver s3c-i2c
[    0.159082] bus: 'platform': really_probe: probing driver s3c-i2c with device 12ce0000.i2c
[    0.159140] s3c-i2c 12ce0000.i2c: slave address 0x00
[    0.159153] s3c-i2c 12ce0000.i2c: bus frequency set to 378 KHz
[    0.159404] s3c-i2c 12ce0000.i2c: i2c-8: S3C I2C adapter
[    0.159416] driver: 's3c-i2c': driver_bound: bound to device '12ce0000.i2c'
[    0.159428] bus: 'platform': really_probe: bound device 12ce0000.i2c to driver s3c-i2c
[    0.159600] initcall i2c_adap_s3c_init+0x0/0x10 returned 0 after 24414 usecs
[    0.159617] calling  power_supply_class_init+0x0/0x50 @ 1
[    0.159665] initcall power_supply_class_init+0x0/0x50 returned 0 after 0 usecs
[    0.159684] calling  hwmon_init+0x0/0x34 @ 1
[    0.159728] initcall hwmon_init+0x0/0x34 returned 0 after 0 usecs
[    0.159743] calling  mmc_init+0x0/0x88 @ 1
[    0.159906] initcall mmc_init+0x0/0x88 returned 0 after 0 usecs
[    0.159921] calling  leds_init+0x0/0x4c @ 1
[    0.159966] initcall leds_init+0x0/0x4c returned 0 after 0 usecs
[    0.159983] calling  s2mps11_clk_init+0x0/0x10 @ 1
[    0.160082] initcall s2mps11_clk_init+0x0/0x10 returned 0 after 0 usecs
[    0.160099] calling  exynos3250_cmu_platform_init+0x0/0x18 @ 1
[    0.160321] initcall exynos3250_cmu_platform_init+0x0/0x18 returned -19 after 4882 usecs
[    0.160345] calling  iio_init+0x0/0x94 @ 1
[    0.160421] initcall iio_init+0x0/0x94 returned 0 after 0 usecs
[    0.160437] calling  init_soundcore+0x0/0x40 @ 1
[    0.160483] initcall init_soundcore+0x0/0x40 returned 0 after 0 usecs
[    0.160500] calling  alsa_sound_init+0x0/0xb0 @ 1
[    0.160527] Advanced Linux Sound Architecture Driver Initialized.
[    0.160540] initcall alsa_sound_init+0x0/0xb0 returned 0 after 0 usecs
[    0.160556] calling  proto_init+0x0/0xc @ 1
[    0.160573] initcall proto_init+0x0/0xc returned 0 after 0 usecs
[    0.160589] calling  net_dev_init+0x0/0x1e8 @ 1
[    0.161022] initcall net_dev_init+0x0/0x1e8 returned 0 after 0 usecs
[    0.161040] calling  neigh_init+0x0/0xa4 @ 1
[    0.161052] initcall neigh_init+0x0/0xa4 returned 0 after 0 usecs
[    0.161066] calling  genl_init+0x0/0x80 @ 1
[    0.161089] initcall genl_init+0x0/0x80 returned 0 after 0 usecs
[    0.161104] calling  cfg80211_init+0x0/0xe4 @ 1
[    0.161431] initcall cfg80211_init+0x0/0xe4 returned 0 after 0 usecs
[    0.161448] calling  watchdog_init+0x0/0xc0 @ 1
[    0.161497] initcall watchdog_init+0x0/0xc0 returned 0 after 0 usecs
[    0.161583] calling  proc_cpu_init+0x0/0x24 @ 1
[    0.161598] initcall proc_cpu_init+0x0/0x24 returned 0 after 0 usecs
[    0.161614] calling  dma_debug_do_init+0x0/0x8 @ 1
[    0.161625] initcall dma_debug_do_init+0x0/0x8 returned 0 after 0 usecs
[    0.161641] calling  alignment_init+0x0/0xe8 @ 1
[    0.161657] initcall alignment_init+0x0/0xe8 returned 0 after 0 usecs
[    0.161671] calling  clocksource_done_booting+0x0/0x44 @ 1
[    0.161708] clocksource: Switched to clocksource arch_sys_counter
[    0.161721] initcall clocksource_done_booting+0x0/0x44 returned 0 after 19 usecs
[    0.161742] calling  init_pipe_fs+0x0/0x58 @ 1
[    0.161776] initcall init_pipe_fs+0x0/0x58 returned 0 after 21 usecs
[    0.161792] calling  inotify_user_setup+0x0/0x54 @ 1
[    0.161808] initcall inotify_user_setup+0x0/0x54 returned 0 after 3 usecs
[    0.161823] calling  eventpoll_init+0x0/0xfc @ 1
[    0.161841] initcall eventpoll_init+0x0/0xfc returned 0 after 6 usecs
[    0.161857] calling  anon_inode_init+0x0/0x6c @ 1
[    0.161893] initcall anon_inode_init+0x0/0x6c returned 0 after 22 usecs
[    0.161910] calling  proc_cmdline_init+0x0/0x38 @ 1
[    0.161926] initcall proc_cmdline_init+0x0/0x38 returned 0 after 3 usecs
[    0.161942] calling  proc_consoles_init+0x0/0x38 @ 1
[    0.161957] initcall proc_consoles_init+0x0/0x38 returned 0 after 2 usecs
[    0.161973] calling  proc_cpuinfo_init+0x0/0x38 @ 1
[    0.161989] initcall proc_cpuinfo_init+0x0/0x38 returned 0 after 3 usecs
[    0.162005] calling  proc_devices_init+0x0/0x38 @ 1
[    0.162020] initcall proc_devices_init+0x0/0x38 returned 0 after 2 usecs
[    0.162036] calling  proc_interrupts_init+0x0/0x38 @ 1
[    0.162051] initcall proc_interrupts_init+0x0/0x38 returned 0 after 2 usecs
[    0.162067] calling  proc_loadavg_init+0x0/0x38 @ 1
[    0.162081] initcall proc_loadavg_init+0x0/0x38 returned 0 after 2 usecs
[    0.162097] calling  proc_meminfo_init+0x0/0x38 @ 1
[    0.162112] initcall proc_meminfo_init+0x0/0x38 returned 0 after 2 usecs
[    0.162128] calling  proc_stat_init+0x0/0x38 @ 1
[    0.162142] initcall proc_stat_init+0x0/0x38 returned 0 after 2 usecs
[    0.162158] calling  proc_uptime_init+0x0/0x38 @ 1
[    0.162173] initcall proc_uptime_init+0x0/0x38 returned 0 after 2 usecs
[    0.162189] calling  proc_version_init+0x0/0x38 @ 1
[    0.162204] initcall proc_version_init+0x0/0x38 returned 0 after 2 usecs
[    0.162220] calling  proc_softirqs_init+0x0/0x38 @ 1
[    0.162234] initcall proc_softirqs_init+0x0/0x38 returned 0 after 2 usecs
[    0.162250] calling  proc_kmsg_init+0x0/0x38 @ 1
[    0.162265] initcall proc_kmsg_init+0x0/0x38 returned 0 after 2 usecs
[    0.162280] calling  proc_page_init+0x0/0x58 @ 1
[    0.162297] initcall proc_page_init+0x0/0x58 returned 0 after 4 usecs
[    0.162313] calling  init_ramfs_fs+0x0/0x34 @ 1
[    0.162325] initcall init_ramfs_fs+0x0/0x34 returned 0 after 0 usecs
[    0.162339] calling  blk_scsi_ioctl_init+0x0/0xdc @ 1
[    0.162351] initcall blk_scsi_ioctl_init+0x0/0xdc returned 0 after 0 usecs
[    0.162365] calling  fb_console_init+0x0/0x140 @ 1
[    0.162476] initcall fb_console_init+0x0/0x140 returned 0 after 95 usecs
[    0.162493] calling  chr_dev_init+0x0/0xc8 @ 1
[    0.170806] initcall chr_dev_init+0x0/0xc8 returned 0 after 8100 usecs
[    0.170829] calling  firmware_class_init+0x0/0xc8 @ 1
[    0.170844] initcall firmware_class_init+0x0/0xc8 returned 0 after 2 usecs
[    0.170858] calling  thermal_init+0x0/0xb4 @ 1
[    0.171140] initcall thermal_init+0x0/0xb4 returned 0 after 262 usecs
[    0.171157] calling  cpufreq_gov_performance_init+0x0/0xc @ 1
[    0.171171] initcall cpufreq_gov_performance_init+0x0/0xc returned 0 after 1 usecs
[    0.171189] calling  cpufreq_gov_dbs_init+0x0/0xc @ 1
[    0.171202] initcall cpufreq_gov_dbs_init+0x0/0xc returned 0 after 0 usecs
[    0.171220] calling  sysctl_core_init+0x0/0x30 @ 1
[    0.171251] initcall sysctl_core_init+0x0/0x30 returned 0 after 17 usecs
[    0.171265] calling  eth_offload_init+0x0/0x18 @ 1
[    0.171276] initcall eth_offload_init+0x0/0x18 returned 0 after 0 usecs
[    0.171290] calling  inet_init+0x0/0x250 @ 1
[    0.171333] NET: Registered protocol family 2
[    0.171618] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    0.171673] TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
[    0.171813] TCP: Hash tables configured (established 8192 bind 8192)
[    0.171862] UDP hash table entries: 512 (order: 2, 24576 bytes)
[    0.171891] UDP-Lite hash table entries: 512 (order: 2, 24576 bytes)
[    0.171998] initcall inet_init+0x0/0x250 returned 0 after 677 usecs
[    0.172015] calling  ipv4_offload_init+0x0/0x68 @ 1
[    0.172027] initcall ipv4_offload_init+0x0/0x68 returned 0 after 0 usecs
[    0.172041] calling  af_unix_init+0x0/0x54 @ 1
[    0.172054] NET: Registered protocol family 1
[    0.172075] initcall af_unix_init+0x0/0x54 returned 0 after 21 usecs
[    0.172089] calling  ipv6_offload_init+0x0/0x88 @ 1
[    0.172103] initcall ipv6_offload_init+0x0/0x88 returned 0 after 1 usecs
[    0.172117] calling  init_sunrpc+0x0/0x6c @ 1
[    0.172265] RPC: Registered named UNIX socket transport module.
[    0.172278] RPC: Registered udp transport module.
[    0.172287] RPC: Registered tcp transport module.
[    0.172297] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.172310] initcall init_sunrpc+0x0/0x6c returned 0 after 175 usecs
[    0.172325] calling  populate_rootfs+0x0/0x25c @ 1
[    0.172448] initcall populate_rootfs+0x0/0x25c returned 0 after 106 usecs
[    0.172540] calling  bL_switcher_dummy_if_init+0x0/0xc @ 1
[    0.172686] initcall bL_switcher_dummy_if_init+0x0/0xc returned 0 after 128 usecs
[    0.172709] calling  proc_execdomains_init+0x0/0x38 @ 1
[    0.172727] initcall proc_execdomains_init+0x0/0x38 returned 0 after 4 usecs
[    0.172744] calling  ioresources_init+0x0/0x58 @ 1
[    0.172762] initcall ioresources_init+0x0/0x58 returned 0 after 5 usecs
[    0.172780] calling  init_sched_debug_procfs+0x0/0x3c @ 1
[    0.172796] initcall init_sched_debug_procfs+0x0/0x3c returned 0 after 3 usecs
[    0.172813] calling  irq_gc_init_ops+0x0/0x18 @ 1
[    0.172825] initcall irq_gc_init_ops+0x0/0x18 returned 0 after 1 usecs
[    0.172838] calling  irq_pm_init_ops+0x0/0x18 @ 1
[    0.172849] initcall irq_pm_init_ops+0x0/0x18 returned 0 after 0 usecs
[    0.172862] calling  init_posix_timers+0x0/0x210 @ 1
[    0.172882] initcall init_posix_timers+0x0/0x210 returned 0 after 8 usecs
[    0.172895] calling  init_posix_cpu_timers+0x0/0xdc @ 1
[    0.172907] initcall init_posix_cpu_timers+0x0/0xdc returned 0 after 0 usecs
[    0.172921] calling  timekeeping_init_ops+0x0/0x18 @ 1
[    0.172933] initcall timekeeping_init_ops+0x0/0x18 returned 0 after 0 usecs
[    0.172946] calling  init_clocksource_sysfs+0x0/0x74 @ 1
[    0.173133] initcall init_clocksource_sysfs+0x0/0x74 returned 0 after 169 usecs
[    0.173152] calling  init_timer_list_procfs+0x0/0x3c @ 1
[    0.173168] initcall init_timer_list_procfs+0x0/0x3c returned 0 after 3 usecs
[    0.173182] calling  alarmtimer_init+0x0/0x1a8 @ 1
[    0.173394] bus: 'platform': driver_probe_device: matched device alarmtimer with driver alarmtimer
[    0.173412] bus: 'platform': really_probe: probing driver alarmtimer with device alarmtimer
[    0.173453] alarmtimer: probe of alarmtimer rejects match -19
[    0.173471] initcall alarmtimer_init+0x0/0x1a8 returned 0 after 271 usecs
[    0.173486] calling  clockevents_init_sysfs+0x0/0xdc @ 1
[    0.173809] initcall clockevents_init_sysfs+0x0/0xdc returned 0 after 301 usecs
[    0.173828] calling  sched_clock_syscore_init+0x0/0x18 @ 1
[    0.173840] initcall sched_clock_syscore_init+0x0/0x18 returned 0 after 0 usecs
[    0.173857] calling  futex_init+0x0/0x108 @ 1
[    0.173870] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.173899] initcall futex_init+0x0/0x108 returned 0 after 29 usecs
[    0.173913] calling  proc_modules_init+0x0/0x38 @ 1
[    0.173929] initcall proc_modules_init+0x0/0x38 returned 0 after 4 usecs
[    0.173943] calling  kallsyms_init+0x0/0x38 @ 1
[    0.173957] initcall kallsyms_init+0x0/0x38 returned 0 after 3 usecs
[    0.173971] calling  pid_namespaces_init+0x0/0x40 @ 1
[    0.173987] initcall pid_namespaces_init+0x0/0x40 returned 0 after 4 usecs
[    0.174002] calling  utsname_sysctl_init+0x0/0x18 @ 1
[    0.174026] initcall utsname_sysctl_init+0x0/0x18 returned 0 after 12 usecs
[    0.174041] calling  init_per_zone_wmark_min+0x0/0xbc @ 1
[    0.174059] initcall init_per_zone_wmark_min+0x0/0xbc returned 0 after 5 usecs
[    0.174077] calling  kswapd_init+0x0/0x24 @ 1
[    0.174134] initcall kswapd_init+0x0/0x24 returned 0 after 43 usecs
[    0.174150] calling  extfrag_debug_init+0x0/0x94 @ 1
[    0.174181] initcall extfrag_debug_init+0x0/0x94 returned 0 after 17 usecs
[    0.174196] calling  setup_vmstat+0x0/0x1b4 @ 1
[    0.174219] initcall setup_vmstat+0x0/0x1b4 returned 0 after 12 usecs
[    0.174234] calling  mm_compute_batch_init+0x0/0x5c @ 1
[    0.174246] initcall mm_compute_batch_init+0x0/0x5c returned 0 after 0 usecs
[    0.174261] calling  slab_proc_init+0x0/0x38 @ 1
[    0.174275] initcall slab_proc_init+0x0/0x38 returned 0 after 2 usecs
[    0.174290] calling  workingset_init+0x0/0x50 @ 1
[    0.174302] initcall workingset_init+0x0/0x50 returned 0 after 1 usecs
[    0.174317] calling  proc_vmalloc_init+0x0/0x38 @ 1
[    0.174332] initcall proc_vmalloc_init+0x0/0x38 returned 0 after 3 usecs
[    0.174348] calling  memblock_init_debugfs+0x0/0x78 @ 1
[    0.174372] initcall memblock_init_debugfs+0x0/0x78 returned 0 after 11 usecs
[    0.174387] calling  procswaps_init+0x0/0x38 @ 1
[    0.174402] initcall procswaps_init+0x0/0x38 returned 0 after 2 usecs
[    0.174418] calling  slab_sysfs_init+0x0/0x11c @ 1
[    0.180816] initcall slab_sysfs_init+0x0/0x11c returned 0 after 6232 usecs
[    0.180838] calling  fcntl_init+0x0/0x40 @ 1
[    0.180858] initcall fcntl_init+0x0/0x40 returned 0 after 7 usecs
[    0.180874] calling  proc_filesystems_init+0x0/0x38 @ 1
[    0.180892] initcall proc_filesystems_init+0x0/0x38 returned 0 after 5 usecs
[    0.180909] calling  start_dirtytime_writeback+0x0/0x34 @ 1
[    0.180923] initcall start_dirtytime_writeback+0x0/0x34 returned 0 after 1 usecs
[    0.180942] calling  dio_init+0x0/0x40 @ 1
[    0.180961] initcall dio_init+0x0/0x40 returned 0 after 6 usecs
[    0.180977] calling  fsnotify_mark_init+0x0/0x40 @ 1
[    0.181031] initcall fsnotify_mark_init+0x0/0x40 returned 0 after 39 usecs
[    0.181049] calling  dnotify_init+0x0/0x84 @ 1
[    0.181074] initcall dnotify_init+0x0/0x84 returned 0 after 12 usecs
[    0.181089] calling  aio_setup+0x0/0x88 @ 1
[    0.181137] initcall aio_setup+0x0/0x88 returned 0 after 34 usecs
[    0.181154] calling  proc_locks_init+0x0/0x38 @ 1
[    0.181170] initcall proc_locks_init+0x0/0x38 returned 0 after 3 usecs
[    0.181186] calling  init_mbcache+0x0/0x18 @ 1
[    0.181198] initcall init_mbcache+0x0/0x18 returned 0 after 0 usecs
[    0.181213] calling  init_grace+0x0/0xc @ 1
[    0.181227] initcall init_grace+0x0/0xc returned 0 after 2 usecs
[    0.181242] calling  init_devpts_fs+0x0/0x70 @ 1
[    0.181281] initcall init_devpts_fs+0x0/0x70 returned 0 after 25 usecs
[    0.181298] calling  init_ext2_fs+0x0/0x78 @ 1
[    0.181444] initcall init_ext2_fs+0x0/0x78 returned 0 after 128 usecs
[    0.181462] calling  ext4_init_fs+0x0/0x1ac @ 1
[    0.182207] initcall ext4_init_fs+0x0/0x1ac returned 0 after 714 usecs
[    0.182226] calling  journal_init+0x0/0x118 @ 1
[    0.182652] initcall journal_init+0x0/0x118 returned 0 after 401 usecs
[    0.182670] calling  init_cramfs_fs+0x0/0x38 @ 1
[    0.182700] initcall init_cramfs_fs+0x0/0x38 returned 0 after 16 usecs
[    0.182717] calling  init_fat_fs+0x0/0x64 @ 1
[    0.182984] initcall init_fat_fs+0x0/0x64 returned 0 after 247 usecs
[    0.183003] calling  init_vfat_fs+0x0/0xc @ 1
[    0.183017] initcall init_vfat_fs+0x0/0xc returned 0 after 1 usecs
[    0.183033] calling  init_msdos_fs+0x0/0xc @ 1
[    0.183046] initcall init_msdos_fs+0x0/0xc returned 0 after 1 usecs
[    0.183062] calling  init_nfs_fs+0x0/0x160 @ 1
[    0.183598] initcall init_nfs_fs+0x0/0x160 returned 0 after 509 usecs
[    0.183613] calling  init_nfs_v2+0x0/0x18 @ 1
[    0.183625] initcall init_nfs_v2+0x0/0x18 returned 0 after 0 usecs
[    0.183638] calling  init_nfs_v3+0x0/0x18 @ 1
[    0.183649] initcall init_nfs_v3+0x0/0x18 returned 0 after 0 usecs
[    0.183662] calling  init_nlm+0x0/0x70 @ 1
[    0.183686] initcall init_nlm+0x0/0x70 returned 0 after 12 usecs
[    0.183699] calling  init_nls_cp437+0x0/0x10 @ 1
[    0.183711] initcall init_nls_cp437+0x0/0x10 returned 0 after 0 usecs
[    0.183724] calling  init_nls_ascii+0x0/0x10 @ 1
[    0.183735] initcall init_nls_ascii+0x0/0x10 returned 0 after 0 usecs
[    0.183748] calling  init_nls_iso8859_1+0x0/0x10 @ 1
[    0.183759] initcall init_nls_iso8859_1+0x0/0x10 returned 0 after 0 usecs
[    0.183772] calling  init_romfs_fs+0x0/0x98 @ 1
[    0.183781] romfs: ROMFS MTD (C) 2007 Red Hat, Inc.
[    0.183926] initcall init_romfs_fs+0x0/0x98 returned 0 after 138 usecs
[    0.183941] calling  ipc_init+0x0/0x18 @ 1
[    0.183961] initcall ipc_init+0x0/0x18 returned 0 after 9 usecs
[    0.183974] calling  ipc_sysctl_init+0x0/0x18 @ 1
[    0.183996] initcall ipc_sysctl_init+0x0/0x18 returned 0 after 10 usecs
[    0.184010] calling  crypto_algapi_init+0x0/0x10 @ 1
[    0.184024] initcall crypto_algapi_init+0x0/0x10 returned 0 after 3 usecs
[    0.184038] calling  chainiv_module_init+0x0/0xc @ 1
[    0.184051] initcall chainiv_module_init+0x0/0xc returned 0 after 2 usecs
[    0.184065] calling  eseqiv_module_init+0x0/0xc @ 1
[    0.184076] initcall eseqiv_module_init+0x0/0xc returned 0 after 0 usecs
[    0.184089] calling  crypto_null_mod_init+0x0/0x4c @ 1
[    0.184291] initcall crypto_null_mod_init+0x0/0x4c returned 0 after 184 usecs
[    0.184307] calling  sha256_generic_mod_init+0x0/0x10 @ 1
[    0.184402] initcall sha256_generic_mod_init+0x0/0x10 returned 0 after 79 usecs
[    0.184421] calling  crypto_cbc_module_init+0x0/0xc @ 1
[    0.184433] initcall crypto_cbc_module_init+0x0/0xc returned 0 after 0 usecs
[    0.184446] calling  aes_init+0x0/0xc @ 1
[    0.184503] initcall aes_init+0x0/0xc returned 0 after 43 usecs
[    0.184517] calling  crc32c_mod_init+0x0/0xc @ 1
[    0.184574] initcall crc32c_mod_init+0x0/0xc returned 0 after 43 usecs
[    0.184588] calling  proc_genhd_init+0x0/0x58 @ 1
[    0.184606] initcall proc_genhd_init+0x0/0x58 returned 0 after 6 usecs
[    0.184621] calling  init_emergency_pool+0x0/0x78 @ 1
[    0.184654] bounce: pool size: 64 pages
[    0.184665] initcall init_emergency_pool+0x0/0x78 returned 0 after 32 usecs
[    0.184679] calling  noop_init+0x0/0xc @ 1
[    0.184690] io scheduler noop registered
[    0.184701] initcall noop_init+0x0/0xc returned 0 after 10 usecs
[    0.184714] calling  deadline_init+0x0/0xc @ 1
[    0.184724] io scheduler deadline registered
[    0.184735] initcall deadline_init+0x0/0xc returned 0 after 9 usecs
[    0.184748] calling  cfq_init+0x0/0xa4 @ 1
[    0.184908] io scheduler cfq registered (default)
[    0.184922] initcall cfq_init+0x0/0xa4 returned 0 after 157 usecs
[    0.184936] calling  percpu_counter_startup+0x0/0x1c @ 1
[    0.184950] initcall percpu_counter_startup+0x0/0x1c returned 0 after 2 usecs
[    0.184965] calling  phy_core_init+0x0/0x58 @ 1
[    0.185013] initcall phy_core_init+0x0/0x58 returned 0 after 35 usecs
[    0.185030] calling  exynos_dp_video_phy_driver_init+0x0/0x10 @ 1
[    0.185148] bus: 'platform': driver_probe_device: matched device video-phy@10040720 with driver exynos-dp-video-phy
[    0.185167] bus: 'platform': really_probe: probing driver exynos-dp-video-phy with device video-phy@10040720
[    0.185389] driver: 'exynos-dp-video-phy': driver_bound: bound to device 'video-phy@10040720'
[    0.185409] bus: 'platform': really_probe: bound device video-phy@10040720 to driver exynos-dp-video-phy
[    0.185524] initcall exynos_dp_video_phy_driver_init+0x0/0x10 returned 0 after 468 usecs
[    0.185546] calling  exynos_mipi_video_phy_driver_init+0x0/0x10 @ 1
[    0.185682] initcall exynos_mipi_video_phy_driver_init+0x0/0x10 returned 0 after 119 usecs
[    0.185702] calling  exynos_sata_phy_driver_init+0x0/0x10 @ 1
[    0.185835] initcall exynos_sata_phy_driver_init+0x0/0x10 returned 0 after 115 usecs
[    0.185856] calling  samsung_usb2_phy_driver_init+0x0/0x10 @ 1
[    0.185943] bus: 'platform': driver_probe_device: matched device 12130000.phy with driver samsung-usb2-phy
[    0.185961] bus: 'platform': really_probe: probing driver samsung-usb2-phy with device 12130000.phy
[    0.186427] driver: 'samsung-usb2-phy': driver_bound: bound to device '12130000.phy'
[    0.186444] bus: 'platform': really_probe: bound device 12130000.phy to driver samsung-usb2-phy
[    0.186562] initcall samsung_usb2_phy_driver_init+0x0/0x10 returned 0 after 675 usecs
[    0.186582] calling  exynos5_usb3drd_phy_init+0x0/0x10 @ 1
[    0.186667] bus: 'platform': driver_probe_device: matched device 12100000.phy with driver exynos5_usb3drd_phy
[    0.186684] bus: 'platform': really_probe: probing driver exynos5_usb3drd_phy with device 12100000.phy
[    0.186848] 12100000.phy supply vbus-boost not found, using dummy regulator
[    0.187098] driver: 'exynos5_usb3drd_phy': driver_bound: bound to device '12100000.phy'
[    0.187116] bus: 'platform': really_probe: bound device 12100000.phy to driver exynos5_usb3drd_phy
[    0.187243] initcall exynos5_usb3drd_phy_init+0x0/0x10 returned 0 after 631 usecs
[    0.187264] calling  pwm_samsung_driver_init+0x0/0x10 @ 1
[    0.187360] bus: 'platform': driver_probe_device: matched device 12dd0000.pwm with driver samsung-pwm
[    0.187377] bus: 'platform': really_probe: probing driver samsung-pwm with device 12dd0000.pwm
[    0.187536] driver: 'samsung-pwm': driver_bound: bound to device '12dd0000.pwm'
[    0.187554] bus: 'platform': really_probe: bound device 12dd0000.pwm to driver samsung-pwm
[    0.187674] initcall pwm_samsung_driver_init+0x0/0x10 returned 0 after 386 usecs
[    0.187693] calling  platform_lcd_driver_init+0x0/0x10 @ 1
[    0.187816] initcall platform_lcd_driver_init+0x0/0x10 returned 0 after 106 usecs
[    0.187836] calling  genericbl_driver_init+0x0/0x10 @ 1
[    0.187926] initcall genericbl_driver_init+0x0/0x10 returned 0 after 74 usecs
[    0.187943] calling  pwm_backlight_driver_init+0x0/0x10 @ 1
[    0.188023] bus: 'platform': driver_probe_device: matched device backlight with driver pwm-backlight
[    0.188040] bus: 'platform': really_probe: probing driver pwm-backlight with device backlight
[    0.188109] pwm-backlight backlight: GPIO lookup for consumer enable
[    0.188121] pwm-backlight backlight: using device tree for GPIO lookup
[    0.188140] of_get_named_gpiod_flags: parsed 'enable-gpios' property of node '/backlight[0]' - status (0)
[    0.188208] platform backlight: Driver pwm-backlight requests probe deferral
[    0.188221] platform backlight: Added to deferred list
[    0.188283] initcall pwm_backlight_driver_init+0x0/0x10 returned 0 after 318 usecs
[    0.188304] calling  exynos_mipi_dsi_driver_init+0x0/0x10 @ 1
[    0.188393] initcall exynos_mipi_dsi_driver_init+0x0/0x10 returned 0 after 73 usecs
[    0.188413] calling  pl330_driver_init+0x0/0xc @ 1
[    0.188432] bus: 'amba': driver_probe_device: matched device 121a0000.pdma with driver dma-pl330
[    0.188449] bus: 'amba': really_probe: probing driver dma-pl330 with device 121a0000.pdma
[    0.191215] dma-pl330 121a0000.pdma: Loaded driver for PL330 DMAC-241330
[    0.191232] dma-pl330 121a0000.pdma: 	DBUFF-32x4bytes Num_Chans-8 Num_Peri-32 Num_Events-32
[    0.191253] driver: 'dma-pl330': driver_bound: bound to device '121a0000.pdma'
[    0.191269] bus: 'amba': really_probe: bound device 121a0000.pdma to driver dma-pl330
[    0.191298] bus: 'amba': driver_probe_device: matched device 121b0000.pdma with driver dma-pl330
[    0.191315] bus: 'amba': really_probe: probing driver dma-pl330 with device 121b0000.pdma
[    0.194244] dma-pl330 121b0000.pdma: Loaded driver for PL330 DMAC-241330
[    0.194262] dma-pl330 121b0000.pdma: 	DBUFF-32x4bytes Num_Chans-8 Num_Peri-32 Num_Events-32
[    0.194282] driver: 'dma-pl330': driver_bound: bound to device '121b0000.pdma'
[    0.194298] bus: 'amba': really_probe: bound device 121b0000.pdma to driver dma-pl330
[    0.194327] bus: 'amba': driver_probe_device: matched device 10800000.mdma with driver dma-pl330
[    0.194344] bus: 'amba': really_probe: probing driver dma-pl330 with device 10800000.mdma
[    0.195148] dma-pl330 10800000.mdma: Loaded driver for PL330 DMAC-241330
[    0.195164] dma-pl330 10800000.mdma: 	DBUFF-64x8bytes Num_Chans-8 Num_Peri-1 Num_Events-32
[    0.195183] driver: 'dma-pl330': driver_bound: bound to device '10800000.mdma'
[    0.195198] bus: 'amba': really_probe: bound device 10800000.mdma to driver dma-pl330
[    0.195225] bus: 'amba': driver_probe_device: matched device 11c10000.mdma with driver dma-pl330
[    0.195241] bus: 'amba': really_probe: probing driver dma-pl330 with device 11c10000.mdma
[    0.196010] dma-pl330 11c10000.mdma: Loaded driver for PL330 DMAC-241330
[    0.196024] dma-pl330 11c10000.mdma: 	DBUFF-64x8bytes Num_Chans-8 Num_Peri-1 Num_Events-32
[    0.196042] driver: 'dma-pl330': driver_bound: bound to device '11c10000.mdma'
[    0.196057] bus: 'amba': really_probe: bound device 11c10000.mdma to driver dma-pl330
[    0.196127] initcall pl330_driver_init+0x0/0xc returned 0 after 7517 usecs
[    0.196144] calling  max77802_pmic_driver_init+0x0/0x10 @ 1
[    0.196257] initcall max77802_pmic_driver_init+0x0/0x10 returned 0 after 96 usecs
[    0.196278] calling  s2mpa01_pmic_driver_init+0x0/0x10 @ 1
[    0.196366] initcall s2mpa01_pmic_driver_init+0x0/0x10 returned 0 after 72 usecs
[    0.196385] calling  pty_init+0x0/0x3dc @ 1
[    0.249310] initcall pty_init+0x0/0x3dc returned 0 after 51665 usecs
[    0.249336] calling  sysrq_init+0x0/0xa0 @ 1
[    0.249359] initcall sysrq_init+0x0/0xa0 returned 0 after 9 usecs
[    0.249376] calling  serial8250_init+0x0/0x144 @ 1
[    0.249387] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.250295] bus: 'platform': driver_probe_device: matched device serial8250 with driver serial8250
[    0.250315] bus: 'platform': really_probe: probing driver serial8250 with device serial8250
[    0.250352] driver: 'serial8250': driver_bound: bound to device 'serial8250'
[    0.250365] bus: 'platform': really_probe: bound device serial8250 to driver serial8250
[    0.250428] initcall serial8250_init+0x0/0x144 returned 0 after 1012 usecs
[    0.250446] calling  samsung_serial_driver_init+0x0/0x10 @ 1
[    0.250478] bus: 'platform': driver_probe_device: matched device 12c00000.serial with driver samsung-uart
[    0.250496] bus: 'platform': really_probe: probing driver samsung-uart with device 12c00000.serial
[    0.250603] 12c00000.serial: ttySAC0 at MMIO 0x12c00000 (irq = 56, base_baud = 0) is a S3C6400/10
[    0.250823] driver: 'samsung-uart': driver_bound: bound to device '12c00000.serial'
[    0.250840] bus: 'platform': really_probe: bound device 12c00000.serial to driver samsung-uart
[    0.250861] bus: 'platform': driver_probe_device: matched device 12c10000.serial with driver samsung-uart
[    0.250879] bus: 'platform': really_probe: probing driver samsung-uart with device 12c10000.serial
[    0.250943] 12c10000.serial: ttySAC1 at MMIO 0x12c10000 (irq = 57, base_baud = 0) is a S3C6400/10
[    0.251144] driver: 'samsung-uart': driver_bound: bound to device '12c10000.serial'
[    0.251161] bus: 'platform': really_probe: bound device 12c10000.serial to driver samsung-uart
[    0.251181] bus: 'platform': driver_probe_device: matched device 12c20000.serial with driver samsung-uart
[    0.251198] bus: 'platform': really_probe: probing driver samsung-uart with device 12c20000.serial
[    0.251264] 12c20000.serial: ttySAC2 at MMIO 0x12c20000 (irq = 58, base_baud = 0) is a S3C6400/10
[    0.251468] driver: 'samsung-uart': driver_bound: bound to device '12c20000.serial'
[    0.251484] bus: 'platform': really_probe: bound device 12c20000.serial to driver samsung-uart
[    0.251505] bus: 'platform': driver_probe_device: matched device 12c30000.serial with driver samsung-uart
[    0.251522] bus: 'platform': really_probe: probing driver samsung-uart with device 12c30000.serial
[    0.251585] 12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 59, base_baud = 0) is a S3C6400/10
[    0.251852] driver: 'samsung-uart': driver_bound: bound to device '12c30000.serial'
[    0.251870] bus: 'platform': really_probe: bound device 12c30000.serial to driver samsung-uart
[    0.252163] initcall samsung_serial_driver_init+0x0/0x10 returned 0 after 1660 usecs
[    0.252185] calling  of_platform_serial_driver_init+0x0/0x10 @ 1
[    0.252481] initcall of_platform_serial_driver_init+0x0/0x10 returned 0 after 273 usecs
[    0.252502] calling  hwrng_modinit+0x0/0xc @ 1
[    0.252635] initcall hwrng_modinit+0x0/0xc returned 0 after 116 usecs
[    0.252652] calling  exynos_rng_driver_init+0x0/0x10 @ 1
[    0.252744] initcall exynos_rng_driver_init+0x0/0x10 returned 0 after 76 usecs
[    0.252765] calling  rng_init+0x0/0xc @ 1
[    0.252780] initcall rng_init+0x0/0xc returned 0 after 3 usecs
[    0.252795] calling  tpm_tis_i2c_driver_init+0x0/0x10 @ 1
[    0.252884] initcall tpm_tis_i2c_driver_init+0x0/0x10 returned 0 after 72 usecs
[    0.252904] calling  drm_core_init+0x0/0x104 @ 1
[    0.252967] [drm] Initialized drm 1.1.0 20060810
[    0.252981] initcall drm_core_init+0x0/0x104 returned 0 after 63 usecs
[    0.252996] calling  exynos_drm_init+0x0/0xc0 @ 1
[    0.253134] bus: 'platform': driver_probe_device: matched device 14400000.fimd with driver exynos4-fb
[    0.253152] bus: 'platform': really_probe: probing driver exynos4-fb with device 14400000.fimd
[    0.253290] driver: 'exynos4-fb': driver_bound: bound to device '14400000.fimd'
[    0.253307] bus: 'platform': really_probe: bound device 14400000.fimd to driver exynos4-fb
[    0.253551] bus: 'platform': driver_probe_device: matched device 145b0000.dp-controller with driver exynos-dp
[    0.253570] bus: 'platform': really_probe: probing driver exynos-dp with device 145b0000.dp-controller
[    0.254151] platform 145b0000.dp-controller: Driver exynos-dp requests probe deferral
[    0.254168] platform 145b0000.dp-controller: Added to deferred list
[    0.254605] bus: 'platform': driver_probe_device: matched device 14450000.mixer with driver exynos-mixer
[    0.254623] bus: 'platform': really_probe: probing driver exynos-mixer with device 14450000.mixer
[    0.255125] driver: 'exynos-mixer': driver_bound: bound to device '14450000.mixer'
[    0.255142] bus: 'platform': really_probe: bound device 14450000.mixer to driver exynos-mixer
[    0.255358] bus: 'platform': driver_probe_device: matched device 14530000.hdmi with driver exynos-hdmi
[    0.255376] bus: 'platform': really_probe: probing driver exynos-hdmi with device 14530000.hdmi
[    0.255911] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of node '/hdmi[0]' - status (0)
[    0.256608] [drm:hdmi_probe] *ERROR* failed to get hdmi-en regulator
[    0.256623] [drm:hdmi_probe] *ERROR* hdmi_resources_init failed
[    0.256796] platform 14530000.hdmi: Driver exynos-hdmi requests probe deferral
[    0.256813] platform 14530000.hdmi: Added to deferred list
[    0.256978] bus: 'platform': driver_probe_device: matched device exynos-drm with driver exynos-drm
[    0.256996] bus: 'platform': really_probe: probing driver exynos-drm with device exynos-drm
[    0.257649] driver: 'exynos-drm': driver_bound: bound to device 'exynos-drm'
[    0.257661] bus: 'platform': really_probe: bound device exynos-drm to driver exynos-drm
[    0.257723] initcall exynos_drm_init+0x0/0xc0 returned 0 after 4604 usecs
[    0.257742] calling  panel_simple_init+0x0/0x34 @ 1
[    0.258146] bus: 'platform': driver_probe_device: matched device panel with driver panel-simple
[    0.258162] bus: 'platform': really_probe: probing driver panel-simple with device panel
[    0.258232] platform panel: Driver panel-simple requests probe deferral
[    0.258244] platform panel: Added to deferred list
[    0.258358] initcall panel_simple_init+0x0/0x34 returned 0 after 586 usecs
[    0.258376] calling  s6e8aa0_driver_init+0x0/0x10 @ 1
[    0.258433] initcall s6e8aa0_driver_init+0x0/0x10 returned 0 after 42 usecs
[    0.258450] calling  ptn3460_driver_init+0x0/0x10 @ 1
[    0.258476] bus: 'i2c': driver_probe_device: matched device 7-0020 with driver nxp,ptn3460
[    0.258497] bus: 'i2c': really_probe: probing driver nxp,ptn3460 with device 7-0020
[    0.258554] i2c 7-0020: Driver nxp,ptn3460 requests probe deferral
[    0.258566] i2c 7-0020: Added to deferred list
[    0.258641] initcall ptn3460_driver_init+0x0/0x10 returned 0 after 173 usecs
[    0.258659] calling  ps8622_driver_init+0x0/0x10 @ 1
[    0.258732] initcall ps8622_driver_init+0x0/0x10 returned 0 after 58 usecs
[    0.258751] calling  topology_sysfs_init+0x0/0x7c @ 1
[    0.258812] initcall topology_sysfs_init+0x0/0x7c returned 0 after 47 usecs
[    0.258828] calling  cacheinfo_sysfs_init+0x0/0x94 @ 1
[    0.258841] initcall cacheinfo_sysfs_init+0x0/0x94 returned -2 after 1 usecs
[    0.258857] calling  devcoredump_init+0x0/0x14 @ 1
[    0.258911] initcall devcoredump_init+0x0/0x14 returned 0 after 39 usecs
[    0.258928] calling  brd_init+0x0/0x170 @ 1
[    0.266174] brd: module loaded
[    0.266198] initcall brd_init+0x0/0x170 returned 0 after 7083 usecs
[    0.266215] calling  loop_init+0x0/0x12c @ 1
[    0.270220] loop: module loaded
[    0.270243] initcall loop_init+0x0/0x12c returned 0 after 3917 usecs
[    0.270261] calling  init_cryptoloop+0x0/0x2c @ 1
[    0.270274] initcall init_cryptoloop+0x0/0x2c returned 0 after 0 usecs
[    0.270290] calling  cros_ec_driver_init+0x0/0x10 @ 1
[    0.270378] initcall cros_ec_driver_init+0x0/0x10 returned 0 after 72 usecs
[    0.270396] calling  cros_ec_driver_spi_init+0x0/0xc @ 1
[    0.270455] initcall cros_ec_driver_spi_init+0x0/0xc returned 0 after 43 usecs
[    0.270475] calling  init_sd+0x0/0x164 @ 1
[    0.270603] initcall init_sd+0x0/0x164 returned 0 after 111 usecs
[    0.270620] calling  init_sg+0x0/0x134 @ 1
[    0.270697] initcall init_sg+0x0/0x134 returned 0 after 61 usecs
[    0.270714] calling  s3c64xx_spi_driver_init+0x0/0x10 @ 1
[    0.270835] bus: 'platform': driver_probe_device: matched device 12d30000.spi with driver s3c64xx-spi
[    0.270853] bus: 'platform': really_probe: probing driver s3c64xx-spi with device 12d30000.spi
[    0.271044] of_get_named_gpiod_flags: parsed 'cs-gpios' property of node '/spi@12d30000[0]' - status (0)
[    0.271294] driver: 's3c64xx-spi': driver_bound: bound to device '12d30000.spi'
[    0.271312] bus: 'platform': really_probe: bound device 12d30000.spi to driver s3c64xx-spi
[    0.271506] initcall s3c64xx_spi_driver_init+0x0/0x10 returned 0 after 758 usecs
[    0.271529] calling  net_olddevs_init+0x0/0x6c @ 1
[    0.271546] initcall net_olddevs_init+0x0/0x6c returned 0 after 4 usecs
[    0.271562] calling  smsc911x_init_module+0x0/0x10 @ 1
[    0.271697] initcall smsc911x_init_module+0x0/0x10 returned 0 after 118 usecs
[    0.271770] calling  rtl8152_driver_init+0x0/0x18 @ 1
[    0.271867] usbcore: registered new interface driver r8152
[    0.271883] initcall rtl8152_driver_init+0x0/0x18 returned 0 after 96 usecs
[    0.271900] calling  asix_driver_init+0x0/0x18 @ 1
[    0.271987] usbcore: registered new interface driver asix
[    0.272002] initcall asix_driver_init+0x0/0x18 returned 0 after 86 usecs
[    0.272019] calling  ax88179_178a_driver_init+0x0/0x18 @ 1
[    0.272086] usbcore: registered new interface driver ax88179_178a
[    0.272102] initcall ax88179_178a_driver_init+0x0/0x18 returned 0 after 67 usecs
[    0.272122] calling  cdc_driver_init+0x0/0x18 @ 1
[    0.272192] usbcore: registered new interface driver cdc_ether
[    0.272207] initcall cdc_driver_init+0x0/0x18 returned 0 after 69 usecs
[    0.272223] calling  smsc75xx_driver_init+0x0/0x18 @ 1
[    0.272305] usbcore: registered new interface driver smsc75xx
[    0.272321] initcall smsc75xx_driver_init+0x0/0x18 returned 0 after 82 usecs
[    0.272338] calling  smsc95xx_driver_init+0x0/0x18 @ 1
[    0.272415] usbcore: registered new interface driver smsc95xx
[    0.272430] initcall smsc95xx_driver_init+0x0/0x18 returned 0 after 76 usecs
[    0.272447] calling  net1080_driver_init+0x0/0x18 @ 1
[    0.272510] usbcore: registered new interface driver net1080
[    0.272525] initcall net1080_driver_init+0x0/0x18 returned 0 after 63 usecs
[    0.272541] calling  cdc_subset_driver_init+0x0/0x18 @ 1
[    0.272602] usbcore: registered new interface driver cdc_subset
[    0.272617] initcall cdc_subset_driver_init+0x0/0x18 returned 0 after 61 usecs
[    0.272637] calling  zaurus_driver_init+0x0/0x18 @ 1
[    0.272697] usbcore: registered new interface driver zaurus
[    0.272712] initcall zaurus_driver_init+0x0/0x18 returned 0 after 60 usecs
[    0.272728] calling  usbnet_init+0x0/0x30 @ 1
[    0.272747] initcall usbnet_init+0x0/0x30 returned 0 after 6 usecs
[    0.272763] calling  cdc_ncm_driver_init+0x0/0x18 @ 1
[    0.272837] usbcore: registered new interface driver cdc_ncm
[    0.272852] initcall cdc_ncm_driver_init+0x0/0x18 returned 0 after 73 usecs
[    0.272868] calling  dwc3_driver_init+0x0/0x10 @ 1
[    0.273026] initcall dwc3_driver_init+0x0/0x10 returned 0 after 140 usecs
[    0.273044] calling  dwc3_exynos_driver_init+0x0/0x10 @ 1
[    0.273110] bus: 'platform': driver_probe_device: matched device usb@12000000 with driver exynos-dwc3
[    0.273127] bus: 'platform': really_probe: probing driver exynos-dwc3 with device usb@12000000
[    0.273407] exynos-dwc3 usb@12000000: no suspend clk specified
[    0.273446] usb@12000000 supply vdd33 not found, using dummy regulator
[    0.273499] usb@12000000 supply vdd10 not found, using dummy regulator
[    0.273738] bus: 'platform': driver_probe_device: matched device 12000000.dwc3 with driver dwc3
[    0.273756] bus: 'platform': really_probe: probing driver dwc3 with device 12000000.dwc3
[    0.474148] driver: 'dwc3': driver_bound: bound to device '12000000.dwc3'
[    0.474163] bus: 'platform': really_probe: bound device 12000000.dwc3 to driver dwc3
[    0.474182] driver: 'exynos-dwc3': driver_bound: bound to device 'usb@12000000'
[    0.474198] bus: 'platform': really_probe: bound device usb@12000000 to driver exynos-dwc3
[    0.474322] initcall dwc3_exynos_driver_init+0x0/0x10 returned 0 after 196544 usecs
[    0.474345] calling  dwc2_platform_driver_init+0x0/0x10 @ 1
[    0.474531] initcall dwc2_platform_driver_init+0x0/0x10 returned 0 after 167 usecs
[    0.474554] calling  xhci_plat_init+0x0/0x2c @ 1
[    0.474694] bus: 'platform': driver_probe_device: matched device xhci-hcd.2.auto with driver xhci-hcd
[    0.474712] bus: 'platform': really_probe: probing driver xhci-hcd with device xhci-hcd.2.auto
[    0.474759] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[    0.474785] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 1
[    0.475001] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[    0.475044] xhci-hcd xhci-hcd.2.auto: irq 144, io mem 0x12000000
[    0.475153] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    0.475166] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.475182] usb usb1: Product: xHCI Host Controller
[    0.475192] usb usb1: Manufacturer: Linux 4.3.0-rc5-next-20151013-dirty xhci-hcd
[    0.475207] usb usb1: SerialNumber: xhci-hcd.2.auto
[    0.475534] bus: 'usb': driver_probe_device: matched device usb1 with driver usb
[    0.475551] bus: 'usb': really_probe: probing driver usb with device usb1
[    0.475689] bus: 'usb': driver_probe_device: matched device 1-0:1.0 with driver hub
[    0.475706] bus: 'usb': really_probe: probing driver hub with device 1-0:1.0
[    0.475736] hub 1-0:1.0: USB hub found
[    0.475764] hub 1-0:1.0: 1 port detected
[    0.475881] driver: 'hub': driver_bound: bound to device '1-0:1.0'
[    0.475895] bus: 'usb': really_probe: bound device 1-0:1.0 to driver hub
[    0.475967] driver: 'usb': driver_bound: bound to device 'usb1'
[    0.475979] bus: 'usb': really_probe: bound device usb1 to driver usb
[    0.476058] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[    0.476077] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 2
[    0.476132] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[    0.476211] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[    0.476224] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.476239] usb usb2: Product: xHCI Host Controller
[    0.476250] usb usb2: Manufacturer: Linux 4.3.0-rc5-next-20151013-dirty xhci-hcd
[    0.476265] usb usb2: SerialNumber: xhci-hcd.2.auto
[    0.476551] bus: 'usb': driver_probe_device: matched device usb2 with driver usb
[    0.476568] bus: 'usb': really_probe: probing driver usb with device usb2
[    0.476739] bus: 'usb': driver_probe_device: matched device 2-0:1.0 with driver hub
[    0.476757] bus: 'usb': really_probe: probing driver hub with device 2-0:1.0
[    0.476786] hub 2-0:1.0: USB hub found
[    0.476811] hub 2-0:1.0: 1 port detected
[    0.476926] driver: 'hub': driver_bound: bound to device '2-0:1.0'
[    0.476938] bus: 'usb': really_probe: bound device 2-0:1.0 to driver hub
[    0.477007] driver: 'usb': driver_bound: bound to device 'usb2'
[    0.477019] bus: 'usb': really_probe: bound device usb2 to driver usb
[    0.477098] driver: 'xhci-hcd': driver_bound: bound to device 'xhci-hcd.2.auto'
[    0.477114] bus: 'platform': really_probe: bound device xhci-hcd.2.auto to driver xhci-hcd
[    0.477176] initcall xhci_plat_init+0x0/0x2c returned 0 after 2546 usecs
[    0.477194] calling  ehci_hcd_init+0x0/0x70 @ 1
[    0.477204] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.477217] initcall ehci_hcd_init+0x0/0x70 returned 0 after 10 usecs
[    0.477233] calling  ehci_exynos_init+0x0/0x54 @ 1
[    0.477243] ehci-exynos: EHCI EXYNOS driver
[    0.477322] bus: 'platform': driver_probe_device: matched device 12110000.usb with driver exynos-ehci
[    0.477340] bus: 'platform': really_probe: probing driver exynos-ehci with device 12110000.usb
[    0.477387] of_get_named_gpiod_flags: parsed 'samsung,vbus-gpio' property of node '/usb@12110000[0]' - status (0)
[    0.477587] exynos-ehci 12110000.usb: EHCI Host Controller
[    0.477613] exynos-ehci 12110000.usb: new USB bus registered, assigned bus number 3
[    0.477724] exynos-ehci 12110000.usb: irq 108, io mem 0x12110000
[    0.486728] exynos-ehci 12110000.usb: USB 2.0 started, EHCI 1.00
[    0.486832] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[    0.486846] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.486861] usb usb3: Product: EHCI Host Controller
[    0.486871] usb usb3: Manufacturer: Linux 4.3.0-rc5-next-20151013-dirty ehci_hcd
[    0.486886] usb usb3: SerialNumber: 12110000.usb
[    0.487180] bus: 'usb': driver_probe_device: matched device usb3 with driver usb
[    0.487197] bus: 'usb': really_probe: probing driver usb with device usb3
[    0.487328] bus: 'usb': driver_probe_device: matched device 3-0:1.0 with driver hub
[    0.487345] bus: 'usb': really_probe: probing driver hub with device 3-0:1.0
[    0.487374] hub 3-0:1.0: USB hub found
[    0.487398] hub 3-0:1.0: 3 ports detected
[    0.487630] driver: 'hub': driver_bound: bound to device '3-0:1.0'
[    0.487643] bus: 'usb': really_probe: bound device 3-0:1.0 to driver hub
[    0.487710] driver: 'usb': driver_bound: bound to device 'usb3'
[    0.487723] bus: 'usb': really_probe: bound device usb3 to driver usb
[    0.487796] driver: 'exynos-ehci': driver_bound: bound to device '12110000.usb'
[    0.487812] bus: 'platform': really_probe: bound device 12110000.usb to driver exynos-ehci
[    0.487937] initcall ehci_exynos_init+0x0/0x54 returned 0 after 10437 usecs
[    0.487955] calling  ohci_hcd_mod_init+0x0/0x80 @ 1
[    0.487965] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    0.487985] initcall ohci_hcd_mod_init+0x0/0x80 returned 0 after 17 usecs
[    0.488002] calling  ohci_exynos_init+0x0/0x54 @ 1
[    0.488011] ohci-exynos: OHCI EXYNOS driver
[    0.488085] bus: 'platform': driver_probe_device: matched device 12120000.usb with driver exynos-ohci
[    0.488103] bus: 'platform': really_probe: probing driver exynos-ohci with device 12120000.usb
[    0.488179] exynos-ohci 12120000.usb: USB Host Controller
[    0.488204] exynos-ohci 12120000.usb: new USB bus registered, assigned bus number 4
[    0.488279] exynos-ohci 12120000.usb: irq 108, io mem 0x12120000
[    0.545832] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[    0.545845] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.545861] usb usb4: Product: USB Host Controller
[    0.545871] usb usb4: Manufacturer: Linux 4.3.0-rc5-next-20151013-dirty ohci_hcd
[    0.545886] usb usb4: SerialNumber: 12120000.usb
[    0.546171] bus: 'usb': driver_probe_device: matched device usb4 with driver usb
[    0.546188] bus: 'usb': really_probe: probing driver usb with device usb4
[    0.546322] bus: 'usb': driver_probe_device: matched device 4-0:1.0 with driver hub
[    0.546339] bus: 'usb': really_probe: probing driver hub with device 4-0:1.0
[    0.546368] hub 4-0:1.0: USB hub found
[    0.546394] hub 4-0:1.0: 3 ports detected
[    0.546583] driver: 'hub': driver_bound: bound to device '4-0:1.0'
[    0.546596] bus: 'usb': really_probe: bound device 4-0:1.0 to driver hub
[    0.546667] driver: 'usb': driver_bound: bound to device 'usb4'
[    0.546679] bus: 'usb': really_probe: bound device usb4 to driver usb
[    0.546777] driver: 'exynos-ohci': driver_bound: bound to device '12120000.usb'
[    0.546793] bus: 'platform': really_probe: bound device 12120000.usb to driver exynos-ohci
[    0.546905] initcall ohci_exynos_init+0x0/0x54 returned 0 after 57508 usecs
[    0.546923] calling  xhci_hcd_init+0x0/0x8 @ 1
[    0.546935] initcall xhci_hcd_init+0x0/0x8 returned 0 after 0 usecs
[    0.546951] calling  usb_storage_driver_init+0x0/0x38 @ 1
[    0.547053] usbcore: registered new interface driver usb-storage
[    0.547068] initcall usb_storage_driver_init+0x0/0x38 returned 0 after 100 usecs
[    0.547089] calling  usb3503_init+0x0/0x54 @ 1
[    0.547304] initcall usb3503_init+0x0/0x54 returned 0 after 196 usecs
[    0.547322] calling  gadget_cfs_init+0x0/0x20 @ 1
[    0.547369] initcall gadget_cfs_init+0x0/0x20 returned 0 after 31 usecs
[    0.547386] calling  ecmmod_init+0x0/0xc @ 1
[    0.547399] initcall ecmmod_init+0x0/0xc returned 0 after 1 usecs
[    0.547415] calling  gethmod_init+0x0/0xc @ 1
[    0.547427] initcall gethmod_init+0x0/0xc returned 0 after 0 usecs
[    0.547443] calling  rndismod_init+0x0/0xc @ 1
[    0.547455] initcall rndismod_init+0x0/0xc returned 0 after 0 usecs
[    0.547468] calling  eth_driver_init+0x0/0xc @ 1
[    0.547480] initcall eth_driver_init+0x0/0xc returned -19 after 1 usecs
[    0.547492] calling  serport_init+0x0/0x30 @ 1
[    0.547504] initcall serport_init+0x0/0x30 returned 0 after 0 usecs
[    0.547516] calling  input_leds_init+0x0/0xc @ 1
[    0.547529] initcall input_leds_init+0x0/0xc returned 0 after 1 usecs
[    0.547542] calling  mousedev_init+0x0/0x88 @ 1
[    0.547799] mousedev: PS/2 mouse device common for all mice
[    0.547813] initcall mousedev_init+0x0/0x88 returned 0 after 254 usecs
[    0.547827] calling  evdev_init+0x0/0xc @ 1
[    0.547839] initcall evdev_init+0x0/0xc returned 0 after 1 usecs
[    0.547851] calling  atkbd_init+0x0/0x18 @ 1
[    0.547929] initcall atkbd_init+0x0/0x18 returned 0 after 63 usecs
[    0.547944] calling  cros_ec_keyb_driver_init+0x0/0x10 @ 1
[    0.548078] initcall cros_ec_keyb_driver_init+0x0/0x10 returned 0 after 118 usecs
[    0.548097] calling  samsung_keypad_driver_init+0x0/0x10 @ 1
[    0.548243] initcall samsung_keypad_driver_init+0x0/0x10 returned 0 after 129 usecs
[    0.548261] calling  cyapa_driver_init+0x0/0x10 @ 1
[    0.548283] bus: 'i2c': driver_probe_device: matched device 1-0067 with driver cyapa
[    0.548304] bus: 'i2c': really_probe: probing driver cyapa with device 1-0067
[    0.548768] 1-0067 supply vcc not found, using dummy regulator
[    0.597006] input: Cypress APA Trackpad (cyapa) as /devices/platform/12c70000.i2c/i2c-1/1-0067/input/input0
[    0.597269] driver: 'cyapa': driver_bound: bound to device '1-0067'
[    0.597282] bus: 'i2c': really_probe: bound device 1-0067 to driver cyapa
[    0.597360] initcall cyapa_driver_init+0x0/0x10 returned 0 after 47935 usecs
[    0.597376] calling  mxt_driver_init+0x0/0x10 @ 1
[    0.597448] initcall mxt_driver_init+0x0/0x10 returned 0 after 57 usecs
[    0.597463] calling  max77686_rtc_driver_init+0x0/0x10 @ 1
[    0.597521] bus: 'platform': driver_probe_device: matched device max77686-rtc with driver max77686-rtc
[    0.597539] bus: 'platform': really_probe: probing driver max77686-rtc with device max77686-rtc
[    0.597572] max77686-rtc max77686-rtc: max77686_rtc_probe
[    0.697208] max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
[    0.697535] driver: 'max77686-rtc': driver_bound: bound to device 'max77686-rtc'
[    0.697552] bus: 'platform': really_probe: bound device max77686-rtc to driver max77686-rtc
[    0.697626] initcall max77686_rtc_driver_init+0x0/0x10 returned 0 after 97801 usecs
[    0.697645] calling  max77802_rtc_driver_init+0x0/0x10 @ 1
[    0.697741] initcall max77802_rtc_driver_init+0x0/0x10 returned 0 after 80 usecs
[    0.697759] calling  s3c_rtc_driver_init+0x0/0x10 @ 1
[    0.697795] bus: 'platform': driver_probe_device: matched device 101e0000.rtc with driver s3c-rtc
[    0.697812] bus: 'platform': really_probe: probing driver s3c-rtc with device 101e0000.rtc
[    0.697909] s3c-rtc 101e0000.rtc: failed to find rtc source clock
[    0.697936] platform 101e0000.rtc: Driver s3c-rtc requests probe deferral
[    0.697949] platform 101e0000.rtc: Added to deferred list
[    0.698141] initcall s3c_rtc_driver_init+0x0/0x10 returned 0 after 359 usecs
[    0.698156] calling  s5m_rtc_driver_init+0x0/0x10 @ 1
[    0.698246] initcall s5m_rtc_driver_init+0x0/0x10 returned 0 after 74 usecs
[    0.698260] calling  i2c_dev_init+0x0/0xe0 @ 1
[    0.698270] i2c /dev entries driver
[    0.699243] initcall i2c_dev_init+0x0/0xe0 returned 0 after 946 usecs
[    0.699259] calling  exynos5_i2c_driver_init+0x0/0x10 @ 1
[    0.699457] initcall exynos5_i2c_driver_init+0x0/0x10 returned 0 after 180 usecs
[    0.699477] calling  ec_i2c_tunnel_driver_init+0x0/0x10 @ 1
[    0.699602] initcall ec_i2c_tunnel_driver_init+0x0/0x10 returned 0 after 109 usecs
[    0.699621] calling  i2c_arbitrator_driver_init+0x0/0x10 @ 1
[    0.699699] bus: 'platform': driver_probe_device: matched device i2c-arbitrator with driver i2c-arb-gpio-challenge
[    0.699718] bus: 'platform': really_probe: probing driver i2c-arb-gpio-challenge with device i2c-arbitrator
[    0.699808] of_get_named_gpiod_flags: parsed 'our-claim-gpio' property of node '/i2c-arbitrator[0]' - status (0)
[    0.699839] of_get_named_gpiod_flags: parsed 'their-claim-gpios' property of node '/i2c-arbitrator[0]' - status (0)
[    0.699866] of_get_named_gpiod_flags: can't parse 'their-claim-gpios' property of node '/i2c-arbitrator[1]'
[    0.700358] bus: 'i2c': driver_probe_device: matched device 104-001e with driver cros-ec-i2c
[    0.700375] bus: 'i2c': really_probe: probing driver cros-ec-i2c with device 104-001e
[    0.708772] bus: 'platform': driver_probe_device: matched device i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller with driver cros-ec-keyb
[    0.708793] bus: 'platform': really_probe: probing driver cros-ec-keyb with device i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller
[    0.709002] input: cros_ec as /devices/platform/12ca0000.i2c/i2c-4/i2c-104/104-001e/i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller/input/input1
[    0.709218] driver: 'cros-ec-keyb': driver_bound: bound to device 'i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller'
[    0.709238] bus: 'platform': really_probe: bound device i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller to driver cros-ec-keyb
[    0.709261] cros-ec-i2c 104-001e: Chrome EC device registered
[    0.709272] driver: 'cros-ec-i2c': driver_bound: bound to device '104-001e'
[    0.709284] bus: 'i2c': really_probe: bound device 104-001e to driver cros-ec-i2c
[    0.709397] bus: 'i2c': driver_probe_device: matched device 104-0048 with driver tps65090
[    0.709414] bus: 'i2c': really_probe: probing driver tps65090 with device 104-0048
[    0.709500] tps65090 104-0048: No cache defaults, reading back from HW
[    0.713554] bus: 'platform': driver_probe_device: matched device tps65090-pmic with driver tps65090-pmic
[    0.713572] bus: 'platform': really_probe: probing driver tps65090-pmic with device tps65090-pmic
[    0.713701] of_get_named_gpiod_flags: can't parse 'dcdc-ext-control-gpios' property of node '/i2c-arbitrator/i2c@0/power-regulator[0]'
[    0.713719] of_get_named_gpiod_flags: can't parse 'dcdc-ext-control-gpios' property of node '/i2c-arbitrator/i2c@0/power-regulator[0]'
[    0.713737] of_get_named_gpiod_flags: can't parse 'dcdc-ext-control-gpios' property of node '/i2c-arbitrator/i2c@0/power-regulator[0]'
[    0.727363] driver: 'tps65090-pmic': driver_bound: bound to device 'tps65090-pmic'
[    0.727384] bus: 'platform': really_probe: bound device tps65090-pmic to driver tps65090-pmic
[    0.727564] driver: 'tps65090': driver_bound: bound to device '104-0048'
[    0.727578] bus: 'i2c': really_probe: bound device 104-0048 to driver tps65090
[    0.727614] i2c i2c-4: Added multiplexed i2c bus 104
[    0.727624] driver: 'i2c-arb-gpio-challenge': driver_bound: bound to device 'i2c-arbitrator'
[    0.727640] bus: 'platform': really_probe: bound device i2c-arbitrator to driver i2c-arb-gpio-challenge
[    0.727716] initcall i2c_arbitrator_driver_init+0x0/0x10 returned 0 after 27422 usecs
[    0.727737] calling  sbs_battery_driver_init+0x0/0x10 @ 1
[    0.727771] bus: 'i2c': driver_probe_device: matched device 104-000b with driver sbs-battery
[    0.727788] bus: 'i2c': really_probe: probing driver sbs-battery with device 104-000b
[    0.730061] sbs-battery 104-000b: sbs-battery: battery gas gauge device registered
[    0.730078] driver: 'sbs-battery': driver_bound: bound to device '104-000b'
[    0.730090] bus: 'i2c': really_probe: bound device 104-000b to driver sbs-battery
[    0.730159] initcall sbs_battery_driver_init+0x0/0x10 returned 0 after 2352 usecs
[    0.730178] calling  max17040_i2c_driver_init+0x0/0x10 @ 1
[    0.730248] initcall max17040_i2c_driver_init+0x0/0x10 returned 0 after 55 usecs
[    0.730267] calling  max17042_i2c_driver_init+0x0/0x10 @ 1
[    0.730344] initcall max17042_i2c_driver_init+0x0/0x10 returned 0 after 62 usecs
[    0.730363] calling  max14577_charger_driver_init+0x0/0x10 @ 1
[    0.730471] initcall max14577_charger_driver_init+0x0/0x10 returned 0 after 92 usecs
[    0.730490] calling  max77693_charger_driver_init+0x0/0x10 @ 1
[    0.730583] initcall max77693_charger_driver_init+0x0/0x10 returned 0 after 78 usecs
[    0.730602] calling  tps65090_charger_driver_init+0x0/0x10 @ 1
[    0.730712] bus: 'platform': driver_probe_device: matched device tps65090-charger with driver tps65090-charger
[    0.730731] bus: 'platform': really_probe: probing driver tps65090-charger with device tps65090-charger
[    0.732656] driver: 'tps65090-charger': driver_bound: bound to device 'tps65090-charger'
[    0.732674] bus: 'platform': really_probe: bound device tps65090-charger to driver tps65090-charger
[    0.732735] initcall tps65090_charger_driver_init+0x0/0x10 returned 0 after 2068 usecs
[    0.732754] calling  ina2xx_driver_init+0x0/0x10 @ 1
[    0.732829] initcall ina2xx_driver_init+0x0/0x10 returned 0 after 60 usecs
[    0.732844] calling  lm90_driver_init+0x0/0x10 @ 1
[    0.732917] initcall lm90_driver_init+0x0/0x10 returned 0 after 59 usecs
[    0.732932] calling  ntc_thermistor_driver_init+0x0/0x10 @ 1
[    0.733197] initcall ntc_thermistor_driver_init+0x0/0x10 returned 0 after 245 usecs
[    0.733216] calling  pwm_fan_driver_init+0x0/0x10 @ 1
[    0.733344] initcall pwm_fan_driver_init+0x0/0x10 returned 0 after 111 usecs
[    0.733359] calling  exynos_tmu_driver_init+0x0/0x10 @ 1
[    0.733457] bus: 'platform': driver_probe_device: matched device 10060000.tmu with driver exynos-tmu
[    0.733474] bus: 'platform': really_probe: probing driver exynos-tmu with device 10060000.tmu
[    0.733535] thermal thermal_zone0: failed to read out thermal zone (-22)
[    0.733583] 10060000.tmu supply vtmu not found, using dummy regulator
[    0.733713] driver: 'exynos-tmu': driver_bound: bound to device '10060000.tmu'
[    0.733730] bus: 'platform': really_probe: bound device 10060000.tmu to driver exynos-tmu
[    0.733960] initcall exynos_tmu_driver_init+0x0/0x10 returned 0 after 573 usecs
[    0.733981] calling  s3c2410wdt_driver_init+0x0/0x10 @ 1
[    0.734041] bus: 'platform': driver_probe_device: matched device 101d0000.watchdog with driver s3c2410-wdt
[    0.734059] bus: 'platform': really_probe: probing driver s3c2410-wdt with device 101d0000.watchdog
[    0.734400] s3c2410-wdt 101d0000.watchdog: watchdog inactive, reset disabled, irq disabled
[    0.734418] driver: 's3c2410-wdt': driver_bound: bound to device '101d0000.watchdog'
[    0.734433] bus: 'platform': really_probe: bound device 101d0000.watchdog to driver s3c2410-wdt
[    0.734587] initcall s3c2410wdt_driver_init+0x0/0x10 returned 0 after 579 usecs
[    0.734606] calling  dm_init+0x0/0x54 @ 1
[    0.734926] device-mapper: ioctl: 4.33.0-ioctl (2015-8-18) initialised: dm-devel@redhat.com
[    0.734945] initcall dm_init+0x0/0x54 returned 0 after 319 usecs
[    0.734960] calling  cpufreq_stats_init+0x0/0xe8 @ 1
[    0.734974] initcall cpufreq_stats_init+0x0/0xe8 returned 0 after 2 usecs
[    0.734989] calling  dt_cpufreq_platdrv_init+0x0/0x10 @ 1
[    0.735012] bus: 'platform': driver_probe_device: matched device cpufreq-dt with driver cpufreq-dt
[    0.735029] bus: 'platform': really_probe: probing driver cpufreq-dt with device cpufreq-dt
[    0.736234] driver: 'cpufreq-dt': driver_bound: bound to device 'cpufreq-dt'
[    0.736249] bus: 'platform': really_probe: bound device cpufreq-dt to driver cpufreq-dt
[    0.736348] initcall dt_cpufreq_platdrv_init+0x0/0x10 returned 0 after 1313 usecs
[    0.736368] calling  exynos_cpufreq_platdrv_init+0x0/0x10 @ 1
[    0.736517] initcall exynos_cpufreq_platdrv_init+0x0/0x10 returned 0 after 131 usecs
[    0.736537] calling  exynos_cpuidle_driver_init+0x0/0x10 @ 1
[    0.736558] bus: 'platform': driver_probe_device: matched device exynos_cpuidle with driver exynos_cpuidle
[    0.736576] bus: 'platform': really_probe: probing driver exynos_cpuidle with device exynos_cpuidle
[    0.736860] driver: 'exynos_cpuidle': driver_bound: bound to device 'exynos_cpuidle'
[    0.736878] bus: 'platform': really_probe: bound device exynos_cpuidle to driver exynos_cpuidle
[    0.736979] initcall exynos_cpuidle_driver_init+0x0/0x10 returned 0 after 418 usecs
[    0.736999] calling  mmc_blk_init+0x0/0x98 @ 1
[    0.737056] initcall mmc_blk_init+0x0/0x98 returned 0 after 43 usecs
[    0.737072] calling  sdhci_drv_init+0x0/0x24 @ 1
[    0.737082] sdhci: Secure Digital Host Controller Interface driver
[    0.737092] sdhci: Copyright(c) Pierre Ossman
[    0.737103] initcall sdhci_drv_init+0x0/0x24 returned 0 after 18 usecs
[    0.737124] calling  sdhci_s3c_driver_init+0x0/0x10 @ 1
[    0.737293] initcall sdhci_s3c_driver_init+0x0/0x10 returned 0 after 151 usecs
[    0.737312] calling  dw_mci_init+0x0/0x18 @ 1
[    0.737321] Synopsys Designware Multimedia Card Interface Driver
[    0.737333] initcall dw_mci_init+0x0/0x18 returned 0 after 9 usecs
[    0.737348] calling  dw_mci_pltfm_driver_init+0x0/0x10 @ 1
[    0.737504] initcall dw_mci_pltfm_driver_init+0x0/0x10 returned 0 after 139 usecs
[    0.737523] calling  dw_mci_exynos_pltfm_driver_init+0x0/0x10 @ 1
[    0.737752] bus: 'platform': driver_probe_device: matched device 12200000.mmc with driver dwmmc_exynos
[    0.737770] bus: 'platform': really_probe: probing driver dwmmc_exynos with device 12200000.mmc
[    0.738028] dwmmc_exynos 12200000.mmc: IDMAC supports 32-bit address mode.
[    0.738082] dwmmc_exynos 12200000.mmc: Using internal DMA controller.
[    0.738098] dwmmc_exynos 12200000.mmc: Version ID is 241a
[    0.738136] dwmmc_exynos 12200000.mmc: DW MMC controller at irq 105,32 bit host data width,128 deep fifo
[    0.738208] dwmmc_exynos 12200000.mmc: No vmmc regulator found
[    0.738220] dwmmc_exynos 12200000.mmc: No vqmmc regulator found
[    0.738237] dwmmc_exynos 12200000.mmc: GPIO lookup for consumer cd
[    0.738248] dwmmc_exynos 12200000.mmc: using device tree for GPIO lookup
[    0.738261] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/mmc@12200000[0]'
[    0.738277] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/mmc@12200000[0]'
[    0.738293] dwmmc_exynos 12200000.mmc: using lookup tables for GPIO lookup
[    0.738305] dwmmc_exynos 12200000.mmc: lookup for GPIO cd failed
[    0.738317] dwmmc_exynos 12200000.mmc: GPIO lookup for consumer wp
[    0.738328] dwmmc_exynos 12200000.mmc: using device tree for GPIO lookup
[    0.738344] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/mmc@12200000[0]'
[    0.738359] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/mmc@12200000[0]'
[    0.738375] dwmmc_exynos 12200000.mmc: using lookup tables for GPIO lookup
[    0.738386] dwmmc_exynos 12200000.mmc: lookup for GPIO wp failed
[    0.766769] dwmmc_exynos 12200000.mmc: 1 slots initialized
[    0.766782] driver: 'dwmmc_exynos': driver_bound: bound to device '12200000.mmc'
[    0.766799] bus: 'platform': really_probe: bound device 12200000.mmc to driver dwmmc_exynos
[    0.766820] bus: 'platform': driver_probe_device: matched device 12220000.mmc with driver dwmmc_exynos
[    0.766837] bus: 'platform': really_probe: probing driver dwmmc_exynos with device 12220000.mmc
[    0.767133] dwmmc_exynos 12220000.mmc: IDMAC supports 32-bit address mode.
[    0.767170] dwmmc_exynos 12220000.mmc: Using internal DMA controller.
[    0.767186] dwmmc_exynos 12220000.mmc: Version ID is 241a
[    0.767220] dwmmc_exynos 12220000.mmc: DW MMC controller at irq 106,32 bit host data width,128 deep fifo
[    0.767287] dwmmc_exynos 12220000.mmc: No vmmc regulator found
[    0.767298] dwmmc_exynos 12220000.mmc: No vqmmc regulator found
[    0.767315] dwmmc_exynos 12220000.mmc: GPIO lookup for consumer cd
[    0.767326] dwmmc_exynos 12220000.mmc: using device tree for GPIO lookup
[    0.767338] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/mmc@12220000[0]'
[    0.767355] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/mmc@12220000[0]'
[    0.767370] dwmmc_exynos 12220000.mmc: using lookup tables for GPIO lookup
[    0.767382] dwmmc_exynos 12220000.mmc: lookup for GPIO cd failed
[    0.767394] dwmmc_exynos 12220000.mmc: GPIO lookup for consumer wp
[    0.767405] dwmmc_exynos 12220000.mmc: using device tree for GPIO lookup
[    0.767420] of_get_named_gpiod_flags: parsed 'wp-gpios' property of node '/mmc@12220000[0]' - status (0)
[    0.767449] dwmmc_exynos 12220000.mmc: Got WP GPIO
[    0.781730] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[    0.796758] dwmmc_exynos 12220000.mmc: 1 slots initialized
[    0.796773] driver: 'dwmmc_exynos': driver_bound: bound to device '12220000.mmc'
[    0.796789] bus: 'platform': really_probe: bound device 12220000.mmc to driver dwmmc_exynos
[    0.796810] bus: 'platform': driver_probe_device: matched device 12230000.mmc with driver dwmmc_exynos
[    0.796827] bus: 'platform': really_probe: probing driver dwmmc_exynos with device 12230000.mmc
[    0.797098] dwmmc_exynos 12230000.mmc: IDMAC supports 32-bit address mode.
[    0.797138] dwmmc_exynos 12230000.mmc: Using internal DMA controller.
[    0.797154] dwmmc_exynos 12230000.mmc: Version ID is 241a
[    0.797188] dwmmc_exynos 12230000.mmc: DW MMC controller at irq 107,32 bit host data width,128 deep fifo
[    0.797250] dwmmc_exynos 12230000.mmc: No vmmc regulator found
[    0.797261] dwmmc_exynos 12230000.mmc: No vqmmc regulator found
[    0.797277] dwmmc_exynos 12230000.mmc: GPIO lookup for consumer cd
[    0.797289] dwmmc_exynos 12230000.mmc: using device tree for GPIO lookup
[    0.797301] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/mmc@12230000[0]'
[    0.797318] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/mmc@12230000[0]'
[    0.797333] dwmmc_exynos 12230000.mmc: using lookup tables for GPIO lookup
[    0.797345] dwmmc_exynos 12230000.mmc: lookup for GPIO cd failed
[    0.797357] dwmmc_exynos 12230000.mmc: GPIO lookup for consumer wp
[    0.797368] dwmmc_exynos 12230000.mmc: using device tree for GPIO lookup
[    0.797379] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/mmc@12230000[0]'
[    0.797395] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/mmc@12230000[0]'
[    0.797410] dwmmc_exynos 12230000.mmc: using lookup tables for GPIO lookup
[    0.797422] dwmmc_exynos 12230000.mmc: lookup for GPIO wp failed
[    0.797554] platform 12230000.mmc: Driver dwmmc_exynos requests probe deferral
[    0.797570] platform 12230000.mmc: Added to deferred list
[    0.797714] initcall dw_mci_exynos_pltfm_driver_init+0x0/0x10 returned 0 after 58764 usecs
[    0.797735] calling  gpio_led_driver_init+0x0/0x10 @ 1
[    0.797862] initcall gpio_led_driver_init+0x0/0x10 returned 0 after 111 usecs
[    0.797879] calling  led_pwm_driver_init+0x0/0x10 @ 1
[    0.797990] initcall led_pwm_driver_init+0x0/0x10 returned 0 after 95 usecs
[    0.798006] calling  heartbeat_trig_init+0x0/0x40 @ 1
[    0.798021] initcall heartbeat_trig_init+0x0/0x40 returned 0 after 2 usecs
[    0.798035] calling  hid_init+0x0/0x54 @ 1
[    0.798086] initcall hid_init+0x0/0x54 returned 0 after 38 usecs
[    0.798101] calling  hid_generic_init+0x0/0x18 @ 1
[    0.798146] initcall hid_generic_init+0x0/0x18 returned 0 after 32 usecs
[    0.798161] calling  a4_driver_init+0x0/0x18 @ 1
[    0.798201] initcall a4_driver_init+0x0/0x18 returned 0 after 26 usecs
[    0.798216] calling  apple_driver_init+0x0/0x18 @ 1
[    0.798266] initcall apple_driver_init+0x0/0x18 returned 0 after 37 usecs
[    0.798282] calling  belkin_driver_init+0x0/0x18 @ 1
[    0.798326] initcall belkin_driver_init+0x0/0x18 returned 0 after 31 usecs
[    0.798342] calling  ch_driver_init+0x0/0x18 @ 1
[    0.798380] initcall ch_driver_init+0x0/0x18 returned 0 after 25 usecs
[    0.798395] calling  ch_driver_init+0x0/0x18 @ 1
[    0.798432] initcall ch_driver_init+0x0/0x18 returned 0 after 25 usecs
[    0.798447] calling  cp_driver_init+0x0/0x18 @ 1
[    0.798484] initcall cp_driver_init+0x0/0x18 returned 0 after 25 usecs
[    0.798499] calling  ez_driver_init+0x0/0x18 @ 1
[    0.798538] initcall ez_driver_init+0x0/0x18 returned 0 after 26 usecs
[    0.798553] calling  ks_driver_init+0x0/0x18 @ 1
[    0.798590] initcall ks_driver_init+0x0/0x18 returned 0 after 25 usecs
[    0.798605] calling  lg_driver_init+0x0/0x18 @ 1
[    0.798642] initcall lg_driver_init+0x0/0x18 returned 0 after 25 usecs
[    0.798657] calling  ms_driver_init+0x0/0x18 @ 1
[    0.798695] initcall ms_driver_init+0x0/0x18 returned 0 after 25 usecs
[    0.798710] calling  mr_driver_init+0x0/0x18 @ 1
[    0.798750] initcall mr_driver_init+0x0/0x18 returned 0 after 28 usecs
[    0.798765] calling  hid_init+0x0/0x5c @ 1
[    0.798829] usbcore: registered new interface driver usbhid
[    0.798840] usbhid: USB HID core driver
[    0.798851] initcall hid_init+0x0/0x5c returned 0 after 72 usecs
[    0.798866] calling  cros_ec_dev_init+0x0/0xd4 @ 1
[    0.798938] bus: 'platform': driver_probe_device: matched device cros-ec-ctl.3.auto with driver cros-ec-ctl
[    0.798956] bus: 'platform': really_probe: probing driver cros-ec-ctl with device cros-ec-ctl.3.auto
[    0.799149] driver: 'cros-ec-ctl': driver_bound: bound to device 'cros-ec-ctl.3.auto'
[    0.799167] bus: 'platform': really_probe: bound device cros-ec-ctl.3.auto to driver cros-ec-ctl
[    0.799207] initcall cros_ec_dev_init+0x0/0xd4 returned 0 after 320 usecs
[    0.799224] calling  max77686_clk_driver_init+0x0/0x10 @ 1
[    0.799282] bus: 'platform': driver_probe_device: matched device max77686-clk with driver max77686-clk
[    0.799300] bus: 'platform': really_probe: probing driver max77686-clk with device max77686-clk
[    0.799407] driver: 'max77686-clk': driver_bound: bound to device 'max77686-clk'
[    0.799423] bus: 'platform': really_probe: bound device max77686-clk to driver max77686-clk
[    0.799475] initcall max77686_clk_driver_init+0x0/0x10 returned 0 after 230 usecs
[    0.799495] calling  max77802_clk_driver_init+0x0/0x10 @ 1
[    0.799570] initcall max77802_clk_driver_init+0x0/0x10 returned 0 after 60 usecs
[    0.799593] calling  extcon_class_init+0x0/0x20 @ 1
[    0.799622] initcall extcon_class_init+0x0/0x20 returned 0 after 15 usecs
[    0.799639] calling  max14577_muic_driver_init+0x0/0x10 @ 1
[    0.799714] initcall max14577_muic_driver_init+0x0/0x10 returned 0 after 59 usecs
[    0.799736] calling  max77693_muic_driver_init+0x0/0x10 @ 1
[    0.799811] initcall max77693_muic_driver_init+0x0/0x10 returned 0 after 61 usecs
[    0.799832] calling  exynos_adc_driver_init+0x0/0x10 @ 1
[    0.800196] initcall exynos_adc_driver_init+0x0/0x10 returned 0 after 341 usecs
[    0.800219] calling  alsa_timer_init+0x0/0x200 @ 1
[    0.800366] initcall alsa_timer_init+0x0/0x200 returned 0 after 129 usecs
[    0.800385] calling  alsa_pcm_init+0x0/0x6c @ 1
[    0.800402] initcall alsa_pcm_init+0x0/0x6c returned 0 after 4 usecs
[    0.800419] calling  snd_compress_init+0x0/0x8 @ 1
[    0.800431] initcall snd_compress_init+0x0/0x8 returned 0 after 0 usecs
[    0.800447] calling  snd_soc_init+0x0/0x11c @ 1
[    0.800636] bus: 'platform': driver_probe_device: matched device snd-soc-dummy with driver snd-soc-dummy
[    0.800654] bus: 'platform': really_probe: probing driver snd-soc-dummy with device snd-soc-dummy
[    0.800697] driver: 'snd-soc-dummy': driver_bound: bound to device 'snd-soc-dummy'
[    0.800714] bus: 'platform': really_probe: bound device snd-soc-dummy to driver snd-soc-dummy
[    0.800818] initcall snd_soc_init+0x0/0x11c returned 0 after 349 usecs
[    0.800845] calling  max98090_i2c_driver_init+0x0/0x10 @ 1
[    0.800912] initcall max98090_i2c_driver_init+0x0/0x10 returned 0 after 51 usecs
[    0.800934] calling  max98095_i2c_driver_init+0x0/0x10 @ 1
[    0.800958] bus: 'i2c': driver_probe_device: matched device 7-0011 with driver max98095
[    0.800979] bus: 'i2c': really_probe: probing driver max98095 with device 7-0011
[    0.801145] driver: 'max98095': driver_bound: bound to device '7-0011'
[    0.801159] bus: 'i2c': really_probe: bound device 7-0011 to driver max98095
[    0.801212] initcall max98095_i2c_driver_init+0x0/0x10 returned 0 after 256 usecs
[    0.801234] calling  asoc_simple_card_init+0x0/0x10 @ 1
[    0.801356] initcall asoc_simple_card_init+0x0/0x10 returned 0 after 105 usecs
[    0.801378] calling  samsung_i2s_driver_init+0x0/0x10 @ 1
[    0.801468] bus: 'platform': driver_probe_device: matched device 3830000.i2s with driver samsung-i2s
[    0.801485] bus: 'platform': really_probe: probing driver samsung-i2s with device 3830000.i2s
[    0.801739] bus: 'platform': driver_probe_device: matched device samsung-i2s-sec with driver samsung-i2s
[    0.801758] bus: 'platform': really_probe: probing driver samsung-i2s with device samsung-i2s-sec
[    0.801798] driver: 'samsung-i2s': driver_bound: bound to device 'samsung-i2s-sec'
[    0.801814] bus: 'platform': really_probe: bound device samsung-i2s-sec to driver samsung-i2s
[    0.801840] driver: 'samsung-i2s': driver_bound: bound to device '3830000.i2s'
[    0.801855] bus: 'platform': really_probe: bound device 3830000.i2s to driver samsung-i2s
[    0.801982] initcall samsung_i2s_driver_init+0x0/0x10 returned 0 after 574 usecs
[    0.802004] calling  asoc_idma_driver_init+0x0/0x10 @ 1
[    0.802078] initcall asoc_idma_driver_init+0x0/0x10 returned 0 after 59 usecs
[    0.802096] calling  snow_driver_init+0x0/0x10 @ 1
[    0.802200] bus: 'platform': driver_probe_device: matched device sound with driver snow-audio
[    0.802217] bus: 'platform': really_probe: probing driver snow-audio with device sound
[    0.825682] mmc0: MAN_BKOPS_EN bit is not set
[    0.828300] mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
[    0.829748] mmc_host mmc0: Bus speed (slot 0) = 100000000Hz (slot req 52000000Hz, actual 50000000HZ div = 1)
[    0.830247] mmc0: new DDR MMC card at address 0001
[    0.830645] bus: 'mmc': driver_probe_device: matched device mmc0:0001 with driver mmcblk
[    0.830694] bus: 'mmc': really_probe: probing driver mmcblk with device mmc0:0001
[    0.831127] mmcblk0: mmc0:0001 SEM16G 14.6 GiB 
[    0.831432] mmcblk0boot0: mmc0:0001 SEM16G partition 1 2.00 MiB
[    0.831814] mmcblk0boot1: mmc0:0001 SEM16G partition 2 2.00 MiB
[    0.832102] mmcblk0rpmb: mmc0:0001 SEM16G partition 3 128 KiB
[    0.836941]  mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12
[    0.844786] driver: 'mmcblk': driver_bound: bound to device 'mmc0:0001'
[    0.844826] bus: 'mmc': really_probe: bound device mmc0:0001 to driver mmcblk
[    0.870562] max98095 7-0011: Hardware revision: C
[    0.879992] snow-audio sound: HiFi <-> 3830000.i2s mapping ok
[    0.880747] max98095 7-0011: ASoC: mux External MIC has no paths
[    0.880794] max98095 7-0011: ASoC: mux Linein Mux has no paths
[    0.883662] driver: 'snow-audio': driver_bound: bound to device 'sound'
[    0.883702] bus: 'platform': really_probe: bound device sound to driver snow-audio
[    0.883860] initcall snow_driver_init+0x0/0x10 returned 0 after 79820 usecs
[    0.883913] calling  odroidx2_audio_driver_init+0x0/0x10 @ 1
[    0.884323] initcall odroidx2_audio_driver_init+0x0/0x10 returned 0 after 361 usecs
[    0.884375] calling  sock_diag_init+0x0/0x50 @ 1
[    0.884457] initcall sock_diag_init+0x0/0x50 returned 0 after 46 usecs
[    0.884500] calling  gre_offload_init+0x0/0x10 @ 1
[    0.884533] initcall gre_offload_init+0x0/0x10 returned 0 after 1 usecs
[    0.884571] calling  sysctl_ipv4_init+0x0/0x54 @ 1
[    0.884768] initcall sysctl_ipv4_init+0x0/0x54 returned 0 after 160 usecs
[    0.884808] calling  xfrm4_beet_init+0x0/0x10 @ 1
[    0.884842] initcall xfrm4_beet_init+0x0/0x10 returned 0 after 2 usecs
[    0.884880] calling  tunnel4_init+0x0/0x70 @ 1
[    0.884911] initcall tunnel4_init+0x0/0x70 returned 0 after 1 usecs
[    0.884949] calling  xfrm4_transport_init+0x0/0x10 @ 1
[    0.884981] initcall xfrm4_transport_init+0x0/0x10 returned 0 after 1 usecs
[    0.885020] calling  xfrm4_mode_tunnel_init+0x0/0x10 @ 1
[    0.885053] initcall xfrm4_mode_tunnel_init+0x0/0x10 returned 0 after 1 usecs
[    0.885091] calling  inet_diag_init+0x0/0x88 @ 1
[    0.885128] initcall inet_diag_init+0x0/0x88 returned 0 after 6 usecs
[    0.885165] calling  tcp_diag_init+0x0/0xc @ 1
[    0.885197] initcall tcp_diag_init+0x0/0xc returned 0 after 2 usecs
[    0.885234] calling  cubictcp_register+0x0/0x64 @ 1
[    0.885267] initcall cubictcp_register+0x0/0x64 returned 0 after 2 usecs
[    0.885305] calling  inet6_init+0x0/0x2c0 @ 1
[    0.887211] NET: Registered protocol family 10
[    0.893144] initcall inet6_init+0x0/0x2c0 returned 0 after 7619 usecs
[    0.893192] calling  xfrm6_transport_init+0x0/0x10 @ 1
[    0.893227] initcall xfrm6_transport_init+0x0/0x10 returned 0 after 1 usecs
[    0.893268] calling  xfrm6_mode_tunnel_init+0x0/0x10 @ 1
[    0.893302] initcall xfrm6_mode_tunnel_init+0x0/0x10 returned 0 after 1 usecs
[    0.893343] calling  xfrm6_beet_init+0x0/0x10 @ 1
[    0.893375] initcall xfrm6_beet_init+0x0/0x10 returned 0 after 1 usecs
[    0.893414] calling  sit_init+0x0/0xc8 @ 1
[    0.893439] sit: IPv6 over IPv4 tunneling driver
[    0.894527] initcall sit_init+0x0/0xc8 returned 0 after 1052 usecs
[    0.894570] calling  packet_init+0x0/0x48 @ 1
[    0.894600] NET: Registered protocol family 17
[    0.894648] initcall packet_init+0x0/0x48 returned 0 after 43 usecs
[    0.894688] calling  ipsec_pfkey_init+0x0/0x78 @ 1
[    0.894731] NET: Registered protocol family 15
[    0.894764] initcall ipsec_pfkey_init+0x0/0x78 returned 0 after 42 usecs
[    0.894987] calling  init_machine_late+0x0/0x98 @ 1
[    0.895378] initcall init_machine_late+0x0/0x98 returned 0 after 349 usecs
[    0.895422] calling  swp_emulation_init+0x0/0x6c @ 1
[    0.895465] Registering SWP/SWPB emulation handler
[    0.895500] initcall swp_emulation_init+0x0/0x6c returned 0 after 44 usecs
[    0.895544] calling  bL_switcher_init+0x0/0xb8 @ 1
[    0.895578] initcall bL_switcher_init+0x0/0xb8 returned -19 after 1 usecs
[    0.895616] calling  init_oops_id+0x0/0x40 @ 1
[    0.895657] initcall init_oops_id+0x0/0x40 returned 0 after 10 usecs
[    0.895704] calling  sched_init_debug+0x0/0x3c @ 1
[    0.895754] initcall sched_init_debug+0x0/0x3c returned 0 after 15 usecs
[    0.895800] calling  pm_qos_power_init+0x0/0xb0 @ 1
[    0.896866] initcall pm_qos_power_init+0x0/0xb0 returned 0 after 1004 usecs
[    0.896919] calling  pm_debugfs_init+0x0/0x38 @ 1
[    0.896966] initcall pm_debugfs_init+0x0/0x38 returned 0 after 12 usecs
[    0.897004] calling  printk_late_init+0x0/0x5c @ 1
[    0.897041] initcall printk_late_init+0x0/0x5c returned 0 after 6 usecs
[    0.897080] calling  tk_debug_sleep_time_init+0x0/0x50 @ 1
[    0.897124] initcall tk_debug_sleep_time_init+0x0/0x50 returned 0 after 11 usecs
[    0.897177] calling  fault_around_debugfs+0x0/0x4c @ 1
[    0.897234] initcall fault_around_debugfs+0x0/0x4c returned 0 after 23 usecs
[    0.897280] calling  max_swapfiles_check+0x0/0x8 @ 1
[    0.897313] initcall max_swapfiles_check+0x0/0x8 returned 0 after 0 usecs
[    0.897351] calling  prandom_reseed+0x0/0x44 @ 1
[    0.897410] initcall prandom_reseed+0x0/0x44 returned 0 after 25 usecs
[    0.897451] calling  fb_logo_late_init+0x0/0x18 @ 1
[    0.897483] initcall fb_logo_late_init+0x0/0x18 returned 0 after 0 usecs
[    0.897528] calling  deferred_probe_initcall+0x0/0x88 @ 1
[    0.897706] platform backlight: Retrying from deferred list
[    0.897819] bus: 'platform': driver_probe_device: matched device backlight with driver pwm-backlight
[    0.897867] bus: 'platform': really_probe: probing driver pwm-backlight with device backlight
[    0.898052] pwm-backlight backlight: GPIO lookup for consumer enable
[    0.898087] pwm-backlight backlight: using device tree for GPIO lookup
[    0.898134] of_get_named_gpiod_flags: parsed 'enable-gpios' property of node '/backlight[0]' - status (0)
[    0.898298] vcd_led: supplied by vbat-supply
[    0.900171] driver: 'pwm-backlight': driver_bound: bound to device 'backlight'
[    0.900227] bus: 'platform': really_probe: bound device backlight to driver pwm-backlight
[    0.900283] platform 145b0000.dp-controller: Retrying from deferred list
[    0.900416] bus: 'platform': driver_probe_device: matched device 145b0000.dp-controller with driver exynos-dp
[    0.900462] bus: 'platform': really_probe: probing driver exynos-dp with device 145b0000.dp-controller
[    0.901117] platform 145b0000.dp-controller: Driver exynos-dp requests probe deferral
[    0.901165] platform 145b0000.dp-controller: Added to deferred list
[    0.901386] platform 14530000.hdmi: Retrying from deferred list
[    0.901527] bus: 'platform': driver_probe_device: matched device 14530000.hdmi with driver exynos-hdmi
[    0.901572] bus: 'platform': really_probe: probing driver exynos-hdmi with device 14530000.hdmi
[    0.902450] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of node '/hdmi[0]' - status (0)
[    0.903637] video_mid_1a: supplied by vbat-supply
[    0.905765] driver: 'exynos-hdmi': driver_bound: bound to device '14530000.hdmi'
[    0.905817] bus: 'platform': really_probe: bound device 14530000.hdmi to driver exynos-hdmi
[    0.905899] platform panel: Retrying from deferred list
[    0.906062] bus: 'platform': driver_probe_device: matched device panel with driver panel-simple
[    0.906109] bus: 'platform': really_probe: probing driver panel-simple with device panel
[    0.906306] lcd_vdd: supplied by vbat-supply
[    0.907007] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[    0.907046] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    0.907234] panel-simple panel: GPIO lookup for consumer enable
[    0.907272] panel-simple panel: using device tree for GPIO lookup
[    0.907306] of_get_named_gpiod_flags: can't parse 'enable-gpios' property of node '/panel[0]'
[    0.907351] of_get_named_gpiod_flags: can't parse 'enable-gpio' property of node '/panel[0]'
[    0.907394] panel-simple panel: using lookup tables for GPIO lookup
[    0.907427] panel-simple panel: lookup for GPIO enable failed
[    0.907558] driver: 'panel-simple': driver_bound: bound to device 'panel'
[    0.907595] bus: 'platform': really_probe: bound device panel to driver panel-simple
[    0.907651] i2c 7-0020: Retrying from deferred list
[    0.907661] bus: 'usb': driver_probe_device: matched device 1-1 with driver usb
[    0.907669] bus: 'usb': really_probe: probing driver usb with device 1-1
[    0.907785] bus: 'i2c': driver_probe_device: matched device 7-0020 with driver nxp,ptn3460
[    0.907831] bus: 'i2c': really_probe: probing driver nxp,ptn3460 with device 7-0020
[    0.907981] nxp,ptn3460 7-0020: GPIO lookup for consumer powerdown
[    0.908014] nxp,ptn3460 7-0020: using device tree for GPIO lookup
[    0.908056] of_get_named_gpiod_flags: parsed 'powerdown-gpios' property of node '/i2c@12CD0000/lvds-bridge@20[0]' - status (0)
[    0.908120] nxp,ptn3460 7-0020: GPIO lookup for consumer reset
[    0.908150] nxp,ptn3460 7-0020: using device tree for GPIO lookup
[    0.908190] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/i2c@12CD0000/lvds-bridge@20[0]' - status (0)
[    0.908252] driver: 'nxp,ptn3460': driver_bound: bound to device '7-0020'
[    0.908286] bus: 'i2c': really_probe: bound device 7-0020 to driver nxp,ptn3460
[    0.908373] platform 101e0000.rtc: Retrying from deferred list
[    0.908572] bus: 'platform': driver_probe_device: matched device 101e0000.rtc with driver s3c-rtc
[    0.908616] bus: 'platform': really_probe: probing driver s3c-rtc with device 101e0000.rtc
[    0.909091] s3c-rtc 101e0000.rtc: rtc disabled, re-enabling
[    0.909614] s3c-rtc 101e0000.rtc: rtc core: registered s3c as rtc1
[    0.909765] driver: 's3c-rtc': driver_bound: bound to device '101e0000.rtc'
[    0.909803] bus: 'platform': really_probe: bound device 101e0000.rtc to driver s3c-rtc
[    0.909858] platform 12230000.mmc: Retrying from deferred list
[    0.910111] bus: 'platform': driver_probe_device: matched device 12230000.mmc with driver dwmmc_exynos
[    0.910156] bus: 'platform': really_probe: probing driver dwmmc_exynos with device 12230000.mmc
[    0.910775] dwmmc_exynos 12230000.mmc: IDMAC supports 32-bit address mode.
[    0.910892] dwmmc_exynos 12230000.mmc: Using internal DMA controller.
[    0.910929] dwmmc_exynos 12230000.mmc: Version ID is 241a
[    0.910983] dwmmc_exynos 12230000.mmc: DW MMC controller at irq 107,32 bit host data width,128 deep fifo
[    0.911167] dwmmc_exynos 12230000.mmc: No vmmc regulator found
[    0.911198] dwmmc_exynos 12230000.mmc: No vqmmc regulator found
[    0.911241] dwmmc_exynos 12230000.mmc: GPIO lookup for consumer cd
[    0.911273] dwmmc_exynos 12230000.mmc: using device tree for GPIO lookup
[    0.911306] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/mmc@12230000[0]'
[    0.911352] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/mmc@12230000[0]'
[    0.911394] dwmmc_exynos 12230000.mmc: using lookup tables for GPIO lookup
[    0.911427] dwmmc_exynos 12230000.mmc: lookup for GPIO cd failed
[    0.911461] dwmmc_exynos 12230000.mmc: GPIO lookup for consumer wp
[    0.911492] dwmmc_exynos 12230000.mmc: using device tree for GPIO lookup
[    0.911524] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/mmc@12230000[0]'
[    0.911567] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/mmc@12230000[0]'
[    0.911609] dwmmc_exynos 12230000.mmc: using lookup tables for GPIO lookup
[    0.911641] dwmmc_exynos 12230000.mmc: lookup for GPIO wp failed
[    0.911898] platform mmc3_pwrseq: GPIO lookup for consumer reset
[    0.911930] platform mmc3_pwrseq: using device tree for GPIO lookup
[    0.911970] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/mmc3_pwrseq[0]' - status (0)
[    0.912030] platform mmc3_pwrseq: GPIO lookup for consumer reset
[    0.912059] platform mmc3_pwrseq: using device tree for GPIO lookup
[    0.912102] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/mmc3_pwrseq[1]' - status (0)
[    0.912160] dwmmc_exynos 12230000.mmc: allocated mmc-pwrseq
[    0.924495] bus: 'usb': driver_probe_device: matched device 1-1:1.0 with driver hub
[    0.924546] bus: 'usb': really_probe: probing driver hub with device 1-1:1.0
[    0.924638] hub 1-1:1.0: USB hub found
[    0.924777] hub 1-1:1.0: 5 ports detected
[    0.941824] dwmmc_exynos 12230000.mmc: 1 slots initialized
[    0.941859] driver: 'dwmmc_exynos': driver_bound: bound to device '12230000.mmc'
[    0.941905] bus: 'platform': really_probe: bound device 12230000.mmc to driver dwmmc_exynos
[    0.941961] platform 145b0000.dp-controller: Retrying from deferred list
[    0.942096] bus: 'platform': driver_probe_device: matched device 145b0000.dp-controller with driver exynos-dp
[    0.942142] bus: 'platform': really_probe: probing driver exynos-dp with device 145b0000.dp-controller
[    0.944121] exynos-drm exynos-drm: bound 14400000.fimd (ops fimd_component_ops)
[    0.944279] of_get_named_gpiod_flags: parsed 'samsung,hpd-gpio' property of node '/dp-controller@145B0000[0]' - status (0)
[    0.945111] exynos-drm exynos-drm: bound 145b0000.dp-controller (ops exynos_dp_ops)
[    0.945297] exynos-drm exynos-drm: bound 14450000.mixer (ops mixer_component_ops)
[    0.945776] exynos-drm exynos-drm: bound 14530000.hdmi (ops hdmi_component_ops)
[    0.945820] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    0.945849] [drm] No driver support for vblank timestamp query.
[    0.957614] driver: 'hub': driver_bound: bound to device '1-1:1.0'
[    0.957657] bus: 'usb': really_probe: bound device 1-1:1.0 to driver hub
[    0.957699] driver: 'usb': driver_bound: bound to device '1-1'
[    0.957735] bus: 'usb': really_probe: bound device 1-1 to driver usb
[    0.998673] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[    1.005565] mmc2: new high speed SDIO card at address 0001
[    1.005772] bus: 'mmc': driver_probe_device: matched device mmc2:0001 with driver mmcblk
[    1.005819] bus: 'mmc': really_probe: probing driver mmcblk with device mmc2:0001
[    1.005927] mmcblk: probe of mmc2:0001 rejects match -19
[    1.164353] exynos-dp 145b0000.dp-controller: EDID data does not include any extensions.
[    1.173729] exynos-dp 145b0000.dp-controller: Link Training Clock Recovery success
[    1.175695] exynos-dp 145b0000.dp-controller: Link Training success!
[    1.241824] usb 1-1.1: new high-speed USB device number 3 using xhci-hcd
[    1.282317] exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok
[    1.282333] exynos-dp 145b0000.dp-controller: unable to config video
[    1.306078] Console: switching to colour frame buffer device 195x54
[    1.339302] exynos-drm exynos-drm: fb0:  frame buffer device
[    1.342018] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[    1.342191] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.343034] bus: 'usb': driver_probe_device: matched device 1-1.1 with driver usb
[    1.343214] bus: 'usb': really_probe: probing driver usb with device 1-1.1
[    1.351767] [drm] Initialized exynos 1.0.0 20110530 on minor 0
[    1.351924] driver: 'exynos-dp': driver_bound: bound to device '145b0000.dp-controller'
[    1.352113] bus: 'platform': really_probe: bound device 145b0000.dp-controller to driver exynos-dp
[    1.352373] initcall deferred_probe_initcall+0x0/0x88 returned 0 after 444139 usecs
[    1.352579] calling  genpd_poweroff_unused+0x0/0x10 @ 1
[    1.352731] initcall genpd_poweroff_unused+0x0/0x10 returned 0 after 17 usecs
[    1.352905] calling  gpio_keys_init+0x0/0x10 @ 1
[    1.353304] bus: 'platform': driver_probe_device: matched device gpio-keys with driver gpio-keys
[    1.353507] bus: 'platform': really_probe: probing driver gpio-keys with device gpio-keys
[    1.353969] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys/power[0]' - status (0)
[    1.354210] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys/lid-switch[0]' - status (0)
[    1.354489] gpio-143 (Power): gpiod_set_debounce: missing set() or set_debounce() operations
[    1.354806] gpio-161 (Lid): gpiod_set_debounce: missing set() or set_debounce() operations
[    1.362148] input: gpio-keys as /devices/platform/gpio-keys/input/input2
[    1.369136] driver: 'gpio-keys': driver_bound: bound to device 'gpio-keys'
[    1.375754] bus: 'platform': really_probe: bound device gpio-keys to driver gpio-keys
[    1.382625] bus: 'usb': driver_probe_device: matched device 1-1.1:1.0 with driver smsc95xx
[    1.389262] initcall gpio_keys_init+0x0/0x10 returned 0 after 35386 usecs
[    1.395759] bus: 'usb': really_probe: probing driver smsc95xx with device 1-1.1:1.0
[    1.402265] calling  rtc_hctosys+0x0/0xf4 @ 1
[    1.408772] smsc95xx v1.0.4
[    1.437322] max77686-rtc max77686-rtc: setting system clock to 2000-01-01 01:57:26 UTC (946691846)
[    1.443937] initcall rtc_hctosys+0x0/0xf4 returned 0 after 28140 usecs
[    1.451588] calling  of_fdt_raw_init+0x0/0x74 @ 1
[    1.458493] initcall of_fdt_raw_init+0x0/0x74 returned 0 after 434 usecs
[    1.461689] calling  clk_debug_init+0x0/0x138 @ 1
[    1.477872] initcall clk_debug_init+0x0/0x138 returned 0 after 12672 usecs
[    1.481044] calling  register_sk_filter_ops+0x0/0x8 @ 1
[    1.484255] initcall register_sk_filter_ops+0x0/0x8 returned 0 after 0 usecs
[    1.487492] calling  tcp_congestion_default+0x0/0xc @ 1
[    1.490691] initcall tcp_congestion_default+0x0/0xc returned 0 after 1 usecs
[    1.493899] calling  ip_auto_config+0x0/0x10b0 @ 1
[    1.514042] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-xhci-hcd.2.auto-1.1, smsc95xx USB 2.0 Ethernet, 94:eb:2c:00:00:a7
[    1.517308] driver: 'smsc95xx': driver_bound: bound to device '1-1.1:1.0'
[    1.520535] bus: 'usb': really_probe: bound device 1-1.1:1.0 to driver smsc95xx
[    1.523776] driver: 'usb': driver_bound: bound to device '1-1.1'
[    1.527000] bus: 'usb': really_probe: bound device 1-1.1 to driver usb
[    2.550550] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[    2.567181] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    4.068149] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
[    4.084229] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[    4.087043] Sending DHCP requests ., OK
[    4.126806] IP-Config: Got DHCP answer from 10.42.0.1, my address is 10.42.0.61
[    4.135375] IP-Config: Complete:
[    4.143386]      device=eth0, hwaddr=94:eb:2c:00:00:a7, ipaddr=10.42.0.61, mask=255.255.255.0, gw=10.42.0.1
[    4.151607]      host=10.42.0.61, domain=, nis-domain=(none)
[    4.159839]      bootserver=10.42.0.1, rootserver=10.42.0.1, rootpath=
[    4.160031]      nameserver0=10.42.0.1

[    4.176184] initcall ip_auto_config+0x0/0x10b0 returned 0 after 2616292 usecs
[    4.184459] calling  regulator_init_complete+0x0/0x48 @ 1
[    4.192736] TPS65090_RAILSDCDC1: disabling
[    4.200927] TPS65090_RAILSDCDC2: disabling
[    4.208995] TPS65090_RAILSDCDC3: disabling
[    4.217785] TPS65090_RAILSLDO1: disabling
[    4.225673] TPS65090_RAILSLDO2: disabling
[    4.233409] initcall regulator_init_complete+0x0/0x48 returned 0 after 39771 usecs
[    4.241321] calling  clk_disable_unused+0x0/0x138 @ 1
[    4.251036] initcall clk_disable_unused+0x0/0x138 returned 0 after 1869 usecs
[    4.253336] calling  alsa_sound_last_init+0x0/0x6c @ 1
[    4.255606] ALSA device list:
[    4.257859]   #0: Snow-I2S-MAX98095
[    4.260076] initcall alsa_sound_last_init+0x0/0x6c returned 0 after 4360 usecs
[    4.262337] calling  init_default_flow_dissectors+0x0/0x3c @ 1
[    4.264559] initcall init_default_flow_dissectors+0x0/0x3c returned 0 after 0 usecs
[    4.280283] VFS: Mounted root (nfs filesystem) on device 0:15.
[    4.283182] devtmpfs: mounted
[    4.285506] Freeing unused kernel memory: 428K (c0797000 - c0802000)
[    4.612617] random: systemd urandom read with 60 bits of entropy available
[    4.620773] systemd[1]: systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR)
[    4.624141] systemd[1]: Detected architecture 'arm'.
[    4.669694] systemd[1]: Failed to insert module 'autofs4'
[    4.675496] systemd[1]: Set hostname to <singularity>.
[    5.336213] systemd[1]: Cannot add dependency job for unit fstrim.timer, ignoring: Unit fstrim.timer failed to load: No such file or directory.
[    5.340944] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory.
[    5.347662] systemd[1]: Starting Forward Password Requests to Wall Directory Watch.
[    5.352548] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[    5.357117] systemd[1]: Starting Remote File Systems (Pre).
[    5.366583] systemd[1]: Reached target Remote File Systems (Pre).
[    5.371155] systemd[1]: Starting Encrypted Volumes.
[    5.380536] systemd[1]: Reached target Encrypted Volumes.
[    5.385193] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[    5.389753] systemd[1]: Starting Swap.
[    5.398864] systemd[1]: Reached target Swap.
[    5.403226] systemd[1]: Starting Root Slice.
[    5.412250] systemd[1]: Created slice Root Slice.
[    5.416473] systemd[1]: Starting Delayed Shutdown Socket.
[    5.425353] systemd[1]: Listening on Delayed Shutdown Socket.
[    5.429611] systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
[    5.439356] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[    5.443581] systemd[1]: Starting Journal Socket (/dev/log).
[    5.453105] systemd[1]: Listening on Journal Socket (/dev/log).
[    5.457315] systemd[1]: Starting udev Control Socket.
[    5.466584] systemd[1]: Listening on udev Control Socket.
[    5.470751] systemd[1]: Starting udev Kernel Socket.
[    5.478879] systemd[1]: Listening on udev Kernel Socket.
[    5.480820] systemd[1]: Starting User and Session Slice.
[    5.484988] systemd[1]: Created slice User and Session Slice.
[    5.486955] systemd[1]: Starting Journal Socket.
[    5.491019] systemd[1]: Listening on Journal Socket.
[    5.492991] systemd[1]: Starting System Slice.
[    5.497088] systemd[1]: Created slice System Slice.
[    5.503932] systemd[1]: Started Set Up Additional Binary Formats.
[    5.505876] systemd[1]: Mounted POSIX Message Queue File System.
[    5.507955] systemd[1]: Mounting Debug File System...
[    5.535382] systemd[1]: Starting Load Kernel Modules...
[    5.541341] systemd[1]: Starting Create list of required static device nodes for the current kernel...
[    5.546898] systemd[1]: Starting udev Coldplug all Devices...
[    5.553220] systemd[1]: Mounted Huge Pages File System.
[    5.555445] systemd[1]: Starting system-getty.slice.
[    5.560549] systemd[1]: Created slice system-getty.slice.
[    5.562837] systemd[1]: Starting Journal Service...
[    5.584166] systemd[1]: Started Journal Service.
[    5.863752] systemd-udevd[1824]: starting version 215
[    6.460842] random: nonblocking pool is initialized
[    7.142323] calling  mwifiex_init_module+0x0/0x10 [mwifiex] @ 2870
[    7.144261] initcall mwifiex_init_module+0x0/0x10 [mwifiex] returned 0 after 11 usecs
[    7.194574] calling  mwifiex_sdio_init_module+0x0/0x54 [mwifiex_sdio] @ 2870
[    7.198388] bus: 'sdio': driver_probe_device: matched device mmc2:0001:1 with driver mwifiex_sdio
[    7.203684] bus: 'sdio': really_probe: probing driver mwifiex_sdio with device mmc2:0001:1
[    7.228437] mwifiex: rx work enabled, cpus 2
[    7.253138] driver: 'mwifiex_sdio': driver_bound: bound to device 'mmc2:0001:1'
[    7.255160] bus: 'sdio': really_probe: bound device mmc2:0001:1 to driver mwifiex_sdio
[    7.265718] initcall mwifiex_sdio_init_module+0x0/0x54 [mwifiex_sdio] returned 0 after 65757 usecs
[    7.956437] mwifiex_sdio mmc2:0001:1: info: FW download over, size 458108 bytes
[    8.271818] mwifiex_sdio mmc2:0001:1: WLAN FW is active
[    8.667367] mwifiex_sdio mmc2:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (14.66.11.p151) 
[    8.672804] mwifiex_sdio mmc2:0001:1: driver_version = mwifiex 1.0 (14.66.11.p151) 
[   11.532582] systemd-journald[1590]: Received request to flush runtime journal from PID 1
[   18.478513] systemd-journald[1590]: Failed to read ACL on /var/log/journal/becefd5da725413ebc34ab1a301f3fc7/user-1001.journal, ignoring: Operation not supported

Re: [GIT PULL] On-demand device probing

[Tim Bird]

On 10/22/2015 11:53 AM, Frank Rowand wrote:
> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>> <oops, sent too early...>
>>
>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>>> But that's moot currently because Greg believes that the time spent
>>> probing devices at boot time could be reduced enough so that the order
>>> in which devices are probed becomes irrelevant. IME that would have to
>>> be under 200ms so that the user doesn't notice and that's unicorn-far
>>> from any bootlog I have ever seen.
>>
>> But as no one has actually produced a bootlog, how do you know that?
>> Where exactly is your time being spent?  What driver is causing long
>> delays?  Why is the long-delay-drivers not being done in their own
>> thread?  And most importantly, why are you ignoring the work that people
>> did back in 2008 to solve the issue on other hardware platforms?
>>
>>> Given that downstreams are already carrying as many hacks as they
>>> could think of to speed total boot up, I think this is effectively
>>> telling them to go away.
>>
>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
>> solve-the-random-issue-i'm-having type patch by putting random calls in
>> semi-random subsystems all over the kernel.
>>
>> And when I ask for real data, you respond with the fact that you aren't
>> trying to speed up boot time here at all, so what am I supposed to think
> 
> I also had the understanding that this patch series was about improving
> boot time.  But I was kindly corrected that the behavior change was
> getting the panel displaying stuff at an earlier point in the boot sequence,
> _not_ completing the entire boot faster. 
> 
> The claim for the current series, in patch 0 in v7 is:
> 
>    With this series I get the kernel to output to the panel in 0.5s,
>    instead of 2.8s.

It's very common to want to get the display up before the
rest of the system.  So wanting to accelerate one part of the boot
at the expense to the rest of the system is a valid use case.
Deferred initcalls, which is out of tree primarily because it requires
the type of manual tweaking that Tomeu describes, specifically
addressed this issue.
> 
> Just to get side-tracked, one other approach at ordering to reduce
> deferrals reported a modest boot time reduction for four boards and a
> very slight boot time increase for one other board.) The report of boot
> times with that approach was in:
> 
>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
> 
> from Alexander Holler.
> 
> I have not searched further to see if there is more data of boot time
> reductions from any of the other attempts to change driver binding
> order to move dependencies before use of a resource.  But whether
> there is a performance improvement or not, there continues to be
> a stream of developers creatively impacting the binding order for
> their specific driver(s) or board.  So it seems that maybe there
> is an underlying problem, or we don't have adequate documentation
> explaining how to avoid a need to order bindings, or the
> documentation exists and is not being read.

Well, I have probe order problems unrelated to boot time, that
I solved by resorting to putting stuff into modules and loading
them post-boot.  So I'd be interested in easy solutions to managing
boot order in mainline.

> 
> I have been defaulting to the position that has been asserted by
> the device tree maintainters, that probe deferrals work just fine
> for at least the majority of cases (and is the message I have been
> sharing in my conference presentations about device tree).  But I
> suspect that there is at least a small minority of cases that are not
> well served by probe deferral.  (Not to be read as an endorsement of
> this specific patch series, just a generic observation.)

I've been worried about DT overhead adding to boot time for a while.
And IMHO probe deferral is just about the lamest way to solve boot
order dependencies I can imagine, from a computer science perspective.
(Well, there's a certain elegance to it, but it's a stupid "make
everything re-doable, back up and start over, time-wasting" elegance.)

However, when Android takes 35 seconds to boot, and most people almost never
cold-boot your product, a few seconds of kernel time-wasting on
cold-boot seem less important. Alas, when I started working on mobile
phones I stopped caring much about boot time.

Thus, I've never worried about the DT overhead enough to actually
measure it, as requested by Greg.  So I'll just shut up now. :-)
 -- Tim
  
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Tim Bird]

On 10/22/2015 11:53 AM, Frank Rowand wrote:
> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>> <oops, sent too early...>
>>
>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>>> But that's moot currently because Greg believes that the time spent
>>> probing devices at boot time could be reduced enough so that the order
>>> in which devices are probed becomes irrelevant. IME that would have to
>>> be under 200ms so that the user doesn't notice and that's unicorn-far
>>> from any bootlog I have ever seen.
>>
>> But as no one has actually produced a bootlog, how do you know that?
>> Where exactly is your time being spent?  What driver is causing long
>> delays?  Why is the long-delay-drivers not being done in their own
>> thread?  And most importantly, why are you ignoring the work that people
>> did back in 2008 to solve the issue on other hardware platforms?
>>
>>> Given that downstreams are already carrying as many hacks as they
>>> could think of to speed total boot up, I think this is effectively
>>> telling them to go away.
>>
>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
>> solve-the-random-issue-i'm-having type patch by putting random calls in
>> semi-random subsystems all over the kernel.
>>
>> And when I ask for real data, you respond with the fact that you aren't
>> trying to speed up boot time here at all, so what am I supposed to think
> 
> I also had the understanding that this patch series was about improving
> boot time.  But I was kindly corrected that the behavior change was
> getting the panel displaying stuff at an earlier point in the boot sequence,
> _not_ completing the entire boot faster. 
> 
> The claim for the current series, in patch 0 in v7 is:
> 
>    With this series I get the kernel to output to the panel in 0.5s,
>    instead of 2.8s.

It's very common to want to get the display up before the
rest of the system.  So wanting to accelerate one part of the boot
at the expense to the rest of the system is a valid use case.
Deferred initcalls, which is out of tree primarily because it requires
the type of manual tweaking that Tomeu describes, specifically
addressed this issue.
> 
> Just to get side-tracked, one other approach at ordering to reduce
> deferrals reported a modest boot time reduction for four boards and a
> very slight boot time increase for one other board.) The report of boot
> times with that approach was in:
> 
>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
> 
> from Alexander Holler.
> 
> I have not searched further to see if there is more data of boot time
> reductions from any of the other attempts to change driver binding
> order to move dependencies before use of a resource.  But whether
> there is a performance improvement or not, there continues to be
> a stream of developers creatively impacting the binding order for
> their specific driver(s) or board.  So it seems that maybe there
> is an underlying problem, or we don't have adequate documentation
> explaining how to avoid a need to order bindings, or the
> documentation exists and is not being read.

Well, I have probe order problems unrelated to boot time, that
I solved by resorting to putting stuff into modules and loading
them post-boot.  So I'd be interested in easy solutions to managing
boot order in mainline.

> 
> I have been defaulting to the position that has been asserted by
> the device tree maintainters, that probe deferrals work just fine
> for at least the majority of cases (and is the message I have been
> sharing in my conference presentations about device tree).  But I
> suspect that there is at least a small minority of cases that are not
> well served by probe deferral.  (Not to be read as an endorsement of
> this specific patch series, just a generic observation.)

I've been worried about DT overhead adding to boot time for a while.
And IMHO probe deferral is just about the lamest way to solve boot
order dependencies I can imagine, from a computer science perspective.
(Well, there's a certain elegance to it, but it's a stupid "make
everything re-doable, back up and start over, time-wasting" elegance.)

However, when Android takes 35 seconds to boot, and most people almost never
cold-boot your product, a few seconds of kernel time-wasting on
cold-boot seem less important. Alas, when I started working on mobile
phones I stopped caring much about boot time.

Thus, I've never worried about the DT overhead enough to actually
measure it, as requested by Greg.  So I'll just shut up now. :-)
 -- Tim
  

Re: [GIT PULL] On-demand device probing

[Tim Bird]

On 10/22/2015 11:53 AM, Frank Rowand wrote:
> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>> <oops, sent too early...>
>>
>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>>> But that's moot currently because Greg believes that the time spent
>>> probing devices at boot time could be reduced enough so that the order
>>> in which devices are probed becomes irrelevant. IME that would have to
>>> be under 200ms so that the user doesn't notice and that's unicorn-far
>>> from any bootlog I have ever seen.
>>
>> But as no one has actually produced a bootlog, how do you know that?
>> Where exactly is your time being spent?  What driver is causing long
>> delays?  Why is the long-delay-drivers not being done in their own
>> thread?  And most importantly, why are you ignoring the work that people
>> did back in 2008 to solve the issue on other hardware platforms?
>>
>>> Given that downstreams are already carrying as many hacks as they
>>> could think of to speed total boot up, I think this is effectively
>>> telling them to go away.
>>
>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
>> solve-the-random-issue-i'm-having type patch by putting random calls in
>> semi-random subsystems all over the kernel.
>>
>> And when I ask for real data, you respond with the fact that you aren't
>> trying to speed up boot time here at all, so what am I supposed to think
> 
> I also had the understanding that this patch series was about improving
> boot time.  But I was kindly corrected that the behavior change was
> getting the panel displaying stuff at an earlier point in the boot sequence,
> _not_ completing the entire boot faster. 
> 
> The claim for the current series, in patch 0 in v7 is:
> 
>    With this series I get the kernel to output to the panel in 0.5s,
>    instead of 2.8s.

It's very common to want to get the display up before the
rest of the system.  So wanting to accelerate one part of the boot
at the expense to the rest of the system is a valid use case.
Deferred initcalls, which is out of tree primarily because it requires
the type of manual tweaking that Tomeu describes, specifically
addressed this issue.
> 
> Just to get side-tracked, one other approach at ordering to reduce
> deferrals reported a modest boot time reduction for four boards and a
> very slight boot time increase for one other board.) The report of boot
> times with that approach was in:
> 
>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
> 
> from Alexander Holler.
> 
> I have not searched further to see if there is more data of boot time
> reductions from any of the other attempts to change driver binding
> order to move dependencies before use of a resource.  But whether
> there is a performance improvement or not, there continues to be
> a stream of developers creatively impacting the binding order for
> their specific driver(s) or board.  So it seems that maybe there
> is an underlying problem, or we don't have adequate documentation
> explaining how to avoid a need to order bindings, or the
> documentation exists and is not being read.

Well, I have probe order problems unrelated to boot time, that
I solved by resorting to putting stuff into modules and loading
them post-boot.  So I'd be interested in easy solutions to managing
boot order in mainline.

> 
> I have been defaulting to the position that has been asserted by
> the device tree maintainters, that probe deferrals work just fine
> for at least the majority of cases (and is the message I have been
> sharing in my conference presentations about device tree).  But I
> suspect that there is at least a small minority of cases that are not
> well served by probe deferral.  (Not to be read as an endorsement of
> this specific patch series, just a generic observation.)

I've been worried about DT overhead adding to boot time for a while.
And IMHO probe deferral is just about the lamest way to solve boot
order dependencies I can imagine, from a computer science perspective.
(Well, there's a certain elegance to it, but it's a stupid "make
everything re-doable, back up and start over, time-wasting" elegance.)

However, when Android takes 35 seconds to boot, and most people almost never
cold-boot your product, a few seconds of kernel time-wasting on
cold-boot seem less important. Alas, when I started working on mobile
phones I stopped caring much about boot time.

Thus, I've never worried about the DT overhead enough to actually
measure it, as requested by Greg.  So I'll just shut up now. :-)
 -- Tim
  

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird <tim.bird@sonymobile.com> wrote:
> On 10/22/2015 11:53 AM, Frank Rowand wrote:
>> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>> <oops, sent too early...>
>>>
>>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>>>> But that's moot currently because Greg believes that the time spent
>>>> probing devices at boot time could be reduced enough so that the order
>>>> in which devices are probed becomes irrelevant. IME that would have to
>>>> be under 200ms so that the user doesn't notice and that's unicorn-far
>>>> from any bootlog I have ever seen.
>>>
>>> But as no one has actually produced a bootlog, how do you know that?
>>> Where exactly is your time being spent?  What driver is causing long
>>> delays?  Why is the long-delay-drivers not being done in their own
>>> thread?  And most importantly, why are you ignoring the work that people
>>> did back in 2008 to solve the issue on other hardware platforms?
>>>
>>>> Given that downstreams are already carrying as many hacks as they
>>>> could think of to speed total boot up, I think this is effectively
>>>> telling them to go away.
>>>
>>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
>>> solve-the-random-issue-i'm-having type patch by putting random calls in
>>> semi-random subsystems all over the kernel.
>>>
>>> And when I ask for real data, you respond with the fact that you aren't
>>> trying to speed up boot time here at all, so what am I supposed to think
>>
>> I also had the understanding that this patch series was about improving
>> boot time.  But I was kindly corrected that the behavior change was
>> getting the panel displaying stuff at an earlier point in the boot sequence,
>> _not_ completing the entire boot faster.
>>
>> The claim for the current series, in patch 0 in v7 is:
>>
>>    With this series I get the kernel to output to the panel in 0.5s,
>>    instead of 2.8s.
>
> It's very common to want to get the display up before the
> rest of the system.  So wanting to accelerate one part of the boot
> at the expense to the rest of the system is a valid use case.
> Deferred initcalls, which is out of tree primarily because it requires
> the type of manual tweaking that Tomeu describes, specifically
> addressed this issue.

Agreed and other folks will want other things up first. But it seems
we are getting lucky with link order with the speed ups in this case.
We need a way to specify priority of probing devices. If we have that
piece, then all this plumbing can be used. A simple solution would be
looking at stdout-path to get the console device to probe. That would
be trivial to add on top of this. That may work for the display too,
but you may not want the console on the display. That wouldn't work
for CAN bus either, but then I'm not sure there is a generic solution
for its requirements (respond within 50ms IIRC).

>> Just to get side-tracked, one other approach at ordering to reduce
>> deferrals reported a modest boot time reduction for four boards and a
>> very slight boot time increase for one other board.) The report of boot
>> times with that approach was in:
>>
>>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
>>
>> from Alexander Holler.
>>
>> I have not searched further to see if there is more data of boot time
>> reductions from any of the other attempts to change driver binding
>> order to move dependencies before use of a resource.  But whether
>> there is a performance improvement or not, there continues to be
>> a stream of developers creatively impacting the binding order for
>> their specific driver(s) or board.  So it seems that maybe there
>> is an underlying problem, or we don't have adequate documentation
>> explaining how to avoid a need to order bindings, or the
>> documentation exists and is not being read.
>
> Well, I have probe order problems unrelated to boot time, that
> I solved by resorting to putting stuff into modules and loading
> them post-boot.  So I'd be interested in easy solutions to managing
> boot order in mainline.

I take it that this series doesn't help those problems?

>> I have been defaulting to the position that has been asserted by
>> the device tree maintainters, that probe deferrals work just fine
>> for at least the majority of cases (and is the message I have been
>> sharing in my conference presentations about device tree).  But I
>> suspect that there is at least a small minority of cases that are not
>> well served by probe deferral.  (Not to be read as an endorsement of
>> this specific patch series, just a generic observation.)
>
> I've been worried about DT overhead adding to boot time for a while.

Always beating up DT... ;) Yes, I'm sure there is some overhead, but
looking at bootgraph there's much longer items not related to DT (USB,
MMC and anything over I2C seem to be typical). With DT we lost most
control of the order, and at the same time we added a load of new
subsystems that are dependencies.

> And IMHO probe deferral is just about the lamest way to solve boot
> order dependencies I can imagine, from a computer science perspective.
> (Well, there's a certain elegance to it, but it's a stupid "make
> everything re-doable, back up and start over, time-wasting" elegance.)

Exactly. That was a large part of my accepting it.

> However, when Android takes 35 seconds to boot, and most people almost never
> cold-boot your product, a few seconds of kernel time-wasting on
> cold-boot seem less important. Alas, when I started working on mobile
> phones I stopped caring much about boot time.
>
> Thus, I've never worried about the DT overhead enough to actually
> measure it, as requested by Greg.  So I'll just shut up now. :-)

That would be a challenge to measure since it is distributed.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird <tim.bird@sonymobile.com> wrote:
> On 10/22/2015 11:53 AM, Frank Rowand wrote:
>> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>> <oops, sent too early...>
>>>
>>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>>>> But that's moot currently because Greg believes that the time spent
>>>> probing devices at boot time could be reduced enough so that the order
>>>> in which devices are probed becomes irrelevant. IME that would have to
>>>> be under 200ms so that the user doesn't notice and that's unicorn-far
>>>> from any bootlog I have ever seen.
>>>
>>> But as no one has actually produced a bootlog, how do you know that?
>>> Where exactly is your time being spent?  What driver is causing long
>>> delays?  Why is the long-delay-drivers not being done in their own
>>> thread?  And most importantly, why are you ignoring the work that people
>>> did back in 2008 to solve the issue on other hardware platforms?
>>>
>>>> Given that downstreams are already carrying as many hacks as they
>>>> could think of to speed total boot up, I think this is effectively
>>>> telling them to go away.
>>>
>>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
>>> solve-the-random-issue-i'm-having type patch by putting random calls in
>>> semi-random subsystems all over the kernel.
>>>
>>> And when I ask for real data, you respond with the fact that you aren't
>>> trying to speed up boot time here at all, so what am I supposed to think
>>
>> I also had the understanding that this patch series was about improving
>> boot time.  But I was kindly corrected that the behavior change was
>> getting the panel displaying stuff at an earlier point in the boot sequence,
>> _not_ completing the entire boot faster.
>>
>> The claim for the current series, in patch 0 in v7 is:
>>
>>    With this series I get the kernel to output to the panel in 0.5s,
>>    instead of 2.8s.
>
> It's very common to want to get the display up before the
> rest of the system.  So wanting to accelerate one part of the boot
> at the expense to the rest of the system is a valid use case.
> Deferred initcalls, which is out of tree primarily because it requires
> the type of manual tweaking that Tomeu describes, specifically
> addressed this issue.

Agreed and other folks will want other things up first. But it seems
we are getting lucky with link order with the speed ups in this case.
We need a way to specify priority of probing devices. If we have that
piece, then all this plumbing can be used. A simple solution would be
looking at stdout-path to get the console device to probe. That would
be trivial to add on top of this. That may work for the display too,
but you may not want the console on the display. That wouldn't work
for CAN bus either, but then I'm not sure there is a generic solution
for its requirements (respond within 50ms IIRC).

>> Just to get side-tracked, one other approach at ordering to reduce
>> deferrals reported a modest boot time reduction for four boards and a
>> very slight boot time increase for one other board.) The report of boot
>> times with that approach was in:
>>
>>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
>>
>> from Alexander Holler.
>>
>> I have not searched further to see if there is more data of boot time
>> reductions from any of the other attempts to change driver binding
>> order to move dependencies before use of a resource.  But whether
>> there is a performance improvement or not, there continues to be
>> a stream of developers creatively impacting the binding order for
>> their specific driver(s) or board.  So it seems that maybe there
>> is an underlying problem, or we don't have adequate documentation
>> explaining how to avoid a need to order bindings, or the
>> documentation exists and is not being read.
>
> Well, I have probe order problems unrelated to boot time, that
> I solved by resorting to putting stuff into modules and loading
> them post-boot.  So I'd be interested in easy solutions to managing
> boot order in mainline.

I take it that this series doesn't help those problems?

>> I have been defaulting to the position that has been asserted by
>> the device tree maintainters, that probe deferrals work just fine
>> for at least the majority of cases (and is the message I have been
>> sharing in my conference presentations about device tree).  But I
>> suspect that there is at least a small minority of cases that are not
>> well served by probe deferral.  (Not to be read as an endorsement of
>> this specific patch series, just a generic observation.)
>
> I've been worried about DT overhead adding to boot time for a while.

Always beating up DT... ;) Yes, I'm sure there is some overhead, but
looking at bootgraph there's much longer items not related to DT (USB,
MMC and anything over I2C seem to be typical). With DT we lost most
control of the order, and at the same time we added a load of new
subsystems that are dependencies.

> And IMHO probe deferral is just about the lamest way to solve boot
> order dependencies I can imagine, from a computer science perspective.
> (Well, there's a certain elegance to it, but it's a stupid "make
> everything re-doable, back up and start over, time-wasting" elegance.)

Exactly. That was a large part of my accepting it.

> However, when Android takes 35 seconds to boot, and most people almost never
> cold-boot your product, a few seconds of kernel time-wasting on
> cold-boot seem less important. Alas, when I started working on mobile
> phones I stopped caring much about boot time.
>
> Thus, I've never worried about the DT overhead enough to actually
> measure it, as requested by Greg.  So I'll just shut up now. :-)

That would be a challenge to measure since it is distributed.

Rob

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird <tim.bird@sonymobile.com> wrote:
> On 10/22/2015 11:53 AM, Frank Rowand wrote:
>> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>> <oops, sent too early...>
>>>
>>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>>>> But that's moot currently because Greg believes that the time spent
>>>> probing devices at boot time could be reduced enough so that the order
>>>> in which devices are probed becomes irrelevant. IME that would have to
>>>> be under 200ms so that the user doesn't notice and that's unicorn-far
>>>> from any bootlog I have ever seen.
>>>
>>> But as no one has actually produced a bootlog, how do you know that?
>>> Where exactly is your time being spent?  What driver is causing long
>>> delays?  Why is the long-delay-drivers not being done in their own
>>> thread?  And most importantly, why are you ignoring the work that people
>>> did back in 2008 to solve the issue on other hardware platforms?
>>>
>>>> Given that downstreams are already carrying as many hacks as they
>>>> could think of to speed total boot up, I think this is effectively
>>>> telling them to go away.
>>>
>>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
>>> solve-the-random-issue-i'm-having type patch by putting random calls in
>>> semi-random subsystems all over the kernel.
>>>
>>> And when I ask for real data, you respond with the fact that you aren't
>>> trying to speed up boot time here at all, so what am I supposed to think
>>
>> I also had the understanding that this patch series was about improving
>> boot time.  But I was kindly corrected that the behavior change was
>> getting the panel displaying stuff at an earlier point in the boot sequence,
>> _not_ completing the entire boot faster.
>>
>> The claim for the current series, in patch 0 in v7 is:
>>
>>    With this series I get the kernel to output to the panel in 0.5s,
>>    instead of 2.8s.
>
> It's very common to want to get the display up before the
> rest of the system.  So wanting to accelerate one part of the boot
> at the expense to the rest of the system is a valid use case.
> Deferred initcalls, which is out of tree primarily because it requires
> the type of manual tweaking that Tomeu describes, specifically
> addressed this issue.

Agreed and other folks will want other things up first. But it seems
we are getting lucky with link order with the speed ups in this case.
We need a way to specify priority of probing devices. If we have that
piece, then all this plumbing can be used. A simple solution would be
looking at stdout-path to get the console device to probe. That would
be trivial to add on top of this. That may work for the display too,
but you may not want the console on the display. That wouldn't work
for CAN bus either, but then I'm not sure there is a generic solution
for its requirements (respond within 50ms IIRC).

>> Just to get side-tracked, one other approach at ordering to reduce
>> deferrals reported a modest boot time reduction for four boards and a
>> very slight boot time increase for one other board.) The report of boot
>> times with that approach was in:
>>
>>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
>>
>> from Alexander Holler.
>>
>> I have not searched further to see if there is more data of boot time
>> reductions from any of the other attempts to change driver binding
>> order to move dependencies before use of a resource.  But whether
>> there is a performance improvement or not, there continues to be
>> a stream of developers creatively impacting the binding order for
>> their specific driver(s) or board.  So it seems that maybe there
>> is an underlying problem, or we don't have adequate documentation
>> explaining how to avoid a need to order bindings, or the
>> documentation exists and is not being read.
>
> Well, I have probe order problems unrelated to boot time, that
> I solved by resorting to putting stuff into modules and loading
> them post-boot.  So I'd be interested in easy solutions to managing
> boot order in mainline.

I take it that this series doesn't help those problems?

>> I have been defaulting to the position that has been asserted by
>> the device tree maintainters, that probe deferrals work just fine
>> for at least the majority of cases (and is the message I have been
>> sharing in my conference presentations about device tree).  But I
>> suspect that there is at least a small minority of cases that are not
>> well served by probe deferral.  (Not to be read as an endorsement of
>> this specific patch series, just a generic observation.)
>
> I've been worried about DT overhead adding to boot time for a while.

Always beating up DT... ;) Yes, I'm sure there is some overhead, but
looking at bootgraph there's much longer items not related to DT (USB,
MMC and anything over I2C seem to be typical). With DT we lost most
control of the order, and at the same time we added a load of new
subsystems that are dependencies.

> And IMHO probe deferral is just about the lamest way to solve boot
> order dependencies I can imagine, from a computer science perspective.
> (Well, there's a certain elegance to it, but it's a stupid "make
> everything re-doable, back up and start over, time-wasting" elegance.)

Exactly. That was a large part of my accepting it.

> However, when Android takes 35 seconds to boot, and most people almost never
> cold-boot your product, a few seconds of kernel time-wasting on
> cold-boot seem less important. Alas, when I started working on mobile
> phones I stopped caring much about boot time.
>
> Thus, I've never worried about the DT overhead enough to actually
> measure it, as requested by Greg.  So I'll just shut up now. :-)

That would be a challenge to measure since it is distributed.

Rob

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Friday, October 23, 2015 11:34:34 AM Rob Herring wrote:
> On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird <tim.bird@sonymobile.com> wrote:
> > On 10/22/2015 11:53 AM, Frank Rowand wrote:
> >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> >>> <oops, sent too early...>
> >>>
> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> >>>> But that's moot currently because Greg believes that the time spent
> >>>> probing devices at boot time could be reduced enough so that the order
> >>>> in which devices are probed becomes irrelevant. IME that would have to
> >>>> be under 200ms so that the user doesn't notice and that's unicorn-far
> >>>> from any bootlog I have ever seen.
> >>>
> >>> But as no one has actually produced a bootlog, how do you know that?
> >>> Where exactly is your time being spent?  What driver is causing long
> >>> delays?  Why is the long-delay-drivers not being done in their own
> >>> thread?  And most importantly, why are you ignoring the work that people
> >>> did back in 2008 to solve the issue on other hardware platforms?
> >>>
> >>>> Given that downstreams are already carrying as many hacks as they
> >>>> could think of to speed total boot up, I think this is effectively
> >>>> telling them to go away.
> >>>
> >>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> >>> solve-the-random-issue-i'm-having type patch by putting random calls in
> >>> semi-random subsystems all over the kernel.
> >>>
> >>> And when I ask for real data, you respond with the fact that you aren't
> >>> trying to speed up boot time here at all, so what am I supposed to think
> >>
> >> I also had the understanding that this patch series was about improving
> >> boot time.  But I was kindly corrected that the behavior change was
> >> getting the panel displaying stuff at an earlier point in the boot sequence,
> >> _not_ completing the entire boot faster.
> >>
> >> The claim for the current series, in patch 0 in v7 is:
> >>
> >>    With this series I get the kernel to output to the panel in 0.5s,
> >>    instead of 2.8s.
> >
> > It's very common to want to get the display up before the
> > rest of the system.  So wanting to accelerate one part of the boot
> > at the expense to the rest of the system is a valid use case.
> > Deferred initcalls, which is out of tree primarily because it requires
> > the type of manual tweaking that Tomeu describes, specifically
> > addressed this issue.
> 
> Agreed and other folks will want other things up first. But it seems
> we are getting lucky with link order with the speed ups in this case.
> We need a way to specify priority of probing devices. If we have that
> piece, then all this plumbing can be used. A simple solution would be
> looking at stdout-path to get the console device to probe. That would
> be trivial to add on top of this. That may work for the display too,
> but you may not want the console on the display. That wouldn't work
> for CAN bus either, but then I'm not sure there is a generic solution
> for its requirements (respond within 50ms IIRC).

Well, I'm not quite sure why exactly everyone is so focused on probing here.

Probing is just one aspect of the fact that we need functional dependencies
to be tracked somehow and acted on when necessary.  And this is not limited
to probing, as I have already said for a few times.  Other cases include:
system shutdown, system suspend/resume, runtime PM, unbinding of drivers.

If there is a functional dependency between two devices (say, B requires A
to be present and functional, meaning that the driver of A has to be present
and working for the driver of B to be working), all of the above need to be
done in a specific order.

Today, however, the driver core only knows about structural dependencies
and only in the specific parent-child case.

So perhaps it's better to start discussing about a solution for the general
issue?

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Friday, October 23, 2015 11:34:34 AM Rob Herring wrote:
> On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird <tim.bird@sonymobile.com> wrote:
> > On 10/22/2015 11:53 AM, Frank Rowand wrote:
> >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> >>> <oops, sent too early...>
> >>>
> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> >>>> But that's moot currently because Greg believes that the time spent
> >>>> probing devices at boot time could be reduced enough so that the order
> >>>> in which devices are probed becomes irrelevant. IME that would have to
> >>>> be under 200ms so that the user doesn't notice and that's unicorn-far
> >>>> from any bootlog I have ever seen.
> >>>
> >>> But as no one has actually produced a bootlog, how do you know that?
> >>> Where exactly is your time being spent?  What driver is causing long
> >>> delays?  Why is the long-delay-drivers not being done in their own
> >>> thread?  And most importantly, why are you ignoring the work that people
> >>> did back in 2008 to solve the issue on other hardware platforms?
> >>>
> >>>> Given that downstreams are already carrying as many hacks as they
> >>>> could think of to speed total boot up, I think this is effectively
> >>>> telling them to go away.
> >>>
> >>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> >>> solve-the-random-issue-i'm-having type patch by putting random calls in
> >>> semi-random subsystems all over the kernel.
> >>>
> >>> And when I ask for real data, you respond with the fact that you aren't
> >>> trying to speed up boot time here at all, so what am I supposed to think
> >>
> >> I also had the understanding that this patch series was about improving
> >> boot time.  But I was kindly corrected that the behavior change was
> >> getting the panel displaying stuff at an earlier point in the boot sequence,
> >> _not_ completing the entire boot faster.
> >>
> >> The claim for the current series, in patch 0 in v7 is:
> >>
> >>    With this series I get the kernel to output to the panel in 0.5s,
> >>    instead of 2.8s.
> >
> > It's very common to want to get the display up before the
> > rest of the system.  So wanting to accelerate one part of the boot
> > at the expense to the rest of the system is a valid use case.
> > Deferred initcalls, which is out of tree primarily because it requires
> > the type of manual tweaking that Tomeu describes, specifically
> > addressed this issue.
> 
> Agreed and other folks will want other things up first. But it seems
> we are getting lucky with link order with the speed ups in this case.
> We need a way to specify priority of probing devices. If we have that
> piece, then all this plumbing can be used. A simple solution would be
> looking at stdout-path to get the console device to probe. That would
> be trivial to add on top of this. That may work for the display too,
> but you may not want the console on the display. That wouldn't work
> for CAN bus either, but then I'm not sure there is a generic solution
> for its requirements (respond within 50ms IIRC).

Well, I'm not quite sure why exactly everyone is so focused on probing here.

Probing is just one aspect of the fact that we need functional dependencies
to be tracked somehow and acted on when necessary.  And this is not limited
to probing, as I have already said for a few times.  Other cases include:
system shutdown, system suspend/resume, runtime PM, unbinding of drivers.

If there is a functional dependency between two devices (say, B requires A
to be present and functional, meaning that the driver of A has to be present
and working for the driver of B to be working), all of the above need to be
done in a specific order.

Today, however, the driver core only knows about structural dependencies
and only in the specific parent-child case.

So perhaps it's better to start discussing about a solution for the general
issue?

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Friday, October 23, 2015 11:34:34 AM Rob Herring wrote:
> On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird <tim.bird@sonymobile.com> wrote:
> > On 10/22/2015 11:53 AM, Frank Rowand wrote:
> >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> >>> <oops, sent too early...>
> >>>
> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> >>>> But that's moot currently because Greg believes that the time spent
> >>>> probing devices at boot time could be reduced enough so that the order
> >>>> in which devices are probed becomes irrelevant. IME that would have to
> >>>> be under 200ms so that the user doesn't notice and that's unicorn-far
> >>>> from any bootlog I have ever seen.
> >>>
> >>> But as no one has actually produced a bootlog, how do you know that?
> >>> Where exactly is your time being spent?  What driver is causing long
> >>> delays?  Why is the long-delay-drivers not being done in their own
> >>> thread?  And most importantly, why are you ignoring the work that people
> >>> did back in 2008 to solve the issue on other hardware platforms?
> >>>
> >>>> Given that downstreams are already carrying as many hacks as they
> >>>> could think of to speed total boot up, I think this is effectively
> >>>> telling them to go away.
> >>>
> >>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> >>> solve-the-random-issue-i'm-having type patch by putting random calls in
> >>> semi-random subsystems all over the kernel.
> >>>
> >>> And when I ask for real data, you respond with the fact that you aren't
> >>> trying to speed up boot time here at all, so what am I supposed to think
> >>
> >> I also had the understanding that this patch series was about improving
> >> boot time.  But I was kindly corrected that the behavior change was
> >> getting the panel displaying stuff at an earlier point in the boot sequence,
> >> _not_ completing the entire boot faster.
> >>
> >> The claim for the current series, in patch 0 in v7 is:
> >>
> >>    With this series I get the kernel to output to the panel in 0.5s,
> >>    instead of 2.8s.
> >
> > It's very common to want to get the display up before the
> > rest of the system.  So wanting to accelerate one part of the boot
> > at the expense to the rest of the system is a valid use case.
> > Deferred initcalls, which is out of tree primarily because it requires
> > the type of manual tweaking that Tomeu describes, specifically
> > addressed this issue.
> 
> Agreed and other folks will want other things up first. But it seems
> we are getting lucky with link order with the speed ups in this case.
> We need a way to specify priority of probing devices. If we have that
> piece, then all this plumbing can be used. A simple solution would be
> looking at stdout-path to get the console device to probe. That would
> be trivial to add on top of this. That may work for the display too,
> but you may not want the console on the display. That wouldn't work
> for CAN bus either, but then I'm not sure there is a generic solution
> for its requirements (respond within 50ms IIRC).

Well, I'm not quite sure why exactly everyone is so focused on probing here.

Probing is just one aspect of the fact that we need functional dependencies
to be tracked somehow and acted on when necessary.  And this is not limited
to probing, as I have already said for a few times.  Other cases include:
system shutdown, system suspend/resume, runtime PM, unbinding of drivers.

If there is a functional dependency between two devices (say, B requires A
to be present and functional, meaning that the driver of A has to be present
and working for the driver of B to be working), all of the above need to be
done in a specific order.

Today, however, the driver core only knows about structural dependencies
and only in the specific parent-child case.

So perhaps it's better to start discussing about a solution for the general
issue?

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Geert Uytterhoeven]

On Thu, Oct 22, 2015 at 8:53 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> I have been defaulting to the position that has been asserted by
> the device tree maintainters, that probe deferrals work just fine
> for at least the majority of cases (and is the message I have been
> sharing in my conference presentations about device tree).  But I
> suspect that there is at least a small minority of cases that are not
> well served by probe deferral.  (Not to be read as an endorsement of
> this specific patch series, just a generic observation.)

Yep, once in a while people still stumble on obscure subsystems and drivers
not supporting probe deferral. Usually they don't fail with a big bang, so
everything seems fine.

E.g. last week's "of_mdiobus_register_phy() and deferred probe"
(https://lkml.org/lkml/2015/10/22/377).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] On-demand device probing

[Geert Uytterhoeven]

On Thu, Oct 22, 2015 at 8:53 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> I have been defaulting to the position that has been asserted by
> the device tree maintainters, that probe deferrals work just fine
> for at least the majority of cases (and is the message I have been
> sharing in my conference presentations about device tree).  But I
> suspect that there is at least a small minority of cases that are not
> well served by probe deferral.  (Not to be read as an endorsement of
> this specific patch series, just a generic observation.)

Yep, once in a while people still stumble on obscure subsystems and drivers
not supporting probe deferral. Usually they don't fail with a big bang, so
everything seems fine.

E.g. last week's "of_mdiobus_register_phy() and deferred probe"
(https://lkml.org/lkml/2015/10/22/377).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] On-demand device probing

[Geert Uytterhoeven]

On Thu, Oct 22, 2015 at 8:53 PM, Frank Rowand <frowand.list@gmail.com> wrote:
> I have been defaulting to the position that has been asserted by
> the device tree maintainters, that probe deferrals work just fine
> for at least the majority of cases (and is the message I have been
> sharing in my conference presentations about device tree).  But I
> suspect that there is at least a small minority of cases that are not
> well served by probe deferral.  (Not to be read as an endorsement of
> this specific patch series, just a generic observation.)

Yep, once in a while people still stumble on obscure subsystems and drivers
not supporting probe deferral. Usually they don't fail with a big bang, so
everything seems fine.

E.g. last week's "of_mdiobus_register_phy() and deferred probe"
(https://lkml.org/lkml/2015/10/22/377).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:

> Well, I'm not quite sure why exactly everyone is so focused on probing here.

Probe deferral is really noisy even if it's working fine on a given
system so it's constantly being highlighted to people in a way that
other issues aren't if you're not directly having problems.

There's also the understanding people had that the order things get
bound changes the ordering for some of the other cases (perhaps it's a
good idea to do that, it seems likely to be sensible?).


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:

> Well, I'm not quite sure why exactly everyone is so focused on probing here.

Probe deferral is really noisy even if it's working fine on a given
system so it's constantly being highlighted to people in a way that
other issues aren't if you're not directly having problems.

There's also the understanding people had that the order things get
bound changes the ordering for some of the other cases (perhaps it's a
good idea to do that, it seems likely to be sensible?).


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:

> Well, I'm not quite sure why exactly everyone is so focused on probing here.

Probe deferral is really noisy even if it's working fine on a given
system so it's constantly being highlighted to people in a way that
other issues aren't if you're not directly having problems.

There's also the understanding people had that the order things get
bound changes the ordering for some of the other cases (perhaps it's a
good idea to do that, it seems likely to be sensible?).


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
> On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>
>> Well, I'm not quite sure why exactly everyone is so focused on probing here.
>
> Probe deferral is really noisy even if it's working fine on a given
> system so it's constantly being highlighted to people in a way that
> other issues aren't if you're not directly having problems.
>
> There's also the understanding people had that the order things get
> bound changes the ordering for some of the other cases (perhaps it's a
> good idea to do that, it seems likely to be sensible?).

But it really doesn't do that.  Also making it do so doesn't help much
in the cases where things can happen asynchronously (system
suspend/resume, runtime PM).

If, instead, there was a way to specify a functional dependency at the
device registration time, it might be used to change the order of
everything relevant, including probe.  That should help to reduce the
noise you're referring to.

If the dependency could only be discovered at the probe time, the
order of things might be changed in response to letting the driver
core know about it rather than "just in case", which should be more
efficient.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
> On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>
>> Well, I'm not quite sure why exactly everyone is so focused on probing here.
>
> Probe deferral is really noisy even if it's working fine on a given
> system so it's constantly being highlighted to people in a way that
> other issues aren't if you're not directly having problems.
>
> There's also the understanding people had that the order things get
> bound changes the ordering for some of the other cases (perhaps it's a
> good idea to do that, it seems likely to be sensible?).

But it really doesn't do that.  Also making it do so doesn't help much
in the cases where things can happen asynchronously (system
suspend/resume, runtime PM).

If, instead, there was a way to specify a functional dependency at the
device registration time, it might be used to change the order of
everything relevant, including probe.  That should help to reduce the
noise you're referring to.

If the dependency could only be discovered at the probe time, the
order of things might be changed in response to letting the driver
core know about it rather than "just in case", which should be more
efficient.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
> On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>
>> Well, I'm not quite sure why exactly everyone is so focused on probing here.
>
> Probe deferral is really noisy even if it's working fine on a given
> system so it's constantly being highlighted to people in a way that
> other issues aren't if you're not directly having problems.
>
> There's also the understanding people had that the order things get
> bound changes the ordering for some of the other cases (perhaps it's a
> good idea to do that, it seems likely to be sensible?).

But it really doesn't do that.  Also making it do so doesn't help much
in the cases where things can happen asynchronously (system
suspend/resume, runtime PM).

If, instead, there was a way to specify a functional dependency at the
device registration time, it might be used to change the order of
everything relevant, including probe.  That should help to reduce the
noise you're referring to.

If the dependency could only be discovered at the probe time, the
order of things might be changed in response to letting the driver
core know about it rather than "just in case", which should be more
efficient.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Andrew F. Davis]

On 10/23/2015 10:45 AM, Tim Bird wrote:
> I've been worried about DT overhead adding to boot time for a while.
> And IMHO probe deferral is just about the lamest way to solve boot
> order dependencies I can imagine, from a computer science perspective.
> (Well, there's a certain elegance to it, but it's a stupid "make
> everything re-doable, back up and start over, time-wasting" elegance.)
>

It has a bogosort kind of elegance. :)

Also this might be a silly question (I haven't been following this issue
for very long), but as the only place that can really know what devices
depend on each other, in a generic kernel, is the DT (or whatever
abstraction) will we not eventually need to solve this issue there? Could
we just add a "depends-on = <&phandle>;" to nodes when we know they are
needed for our board?

Re: [GIT PULL] On-demand device probing

[Andrew F. Davis]

On 10/23/2015 10:45 AM, Tim Bird wrote:
> I've been worried about DT overhead adding to boot time for a while.
> And IMHO probe deferral is just about the lamest way to solve boot
> order dependencies I can imagine, from a computer science perspective.
> (Well, there's a certain elegance to it, but it's a stupid "make
> everything re-doable, back up and start over, time-wasting" elegance.)
>

It has a bogosort kind of elegance. :)

Also this might be a silly question (I haven't been following this issue
for very long), but as the only place that can really know what devices
depend on each other, in a generic kernel, is the DT (or whatever
abstraction) will we not eventually need to solve this issue there? Could
we just add a "depends-on = <&phandle>;" to nodes when we know they are
needed for our board?

Re: [GIT PULL] On-demand device probing

[Andrew F. Davis]

On 10/23/2015 10:45 AM, Tim Bird wrote:
> I've been worried about DT overhead adding to boot time for a while.
> And IMHO probe deferral is just about the lamest way to solve boot
> order dependencies I can imagine, from a computer science perspective.
> (Well, there's a certain elegance to it, but it's a stupid "make
> everything re-doable, back up and start over, time-wasting" elegance.)
>

It has a bogosort kind of elegance. :)

Also this might be a silly question (I haven't been following this issue
for very long), but as the only place that can really know what devices
depend on each other, in a generic kernel, is the DT (or whatever
abstraction) will we not eventually need to solve this issue there? Could
we just add a "depends-on = <&phandle>;" to nodes when we know they are
needed for our board?

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

On Sun, Oct 25, 2015 at 02:54:39PM +0100, Rafael J. Wysocki wrote:
> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:

> > There's also the understanding people had that the order things get
> > bound changes the ordering for some of the other cases (perhaps it's a
> > good idea to do that, it seems likely to be sensible?).

> But it really doesn't do that.  Also making it do so doesn't help much
> in the cases where things can happen asynchronously (system
> suspend/resume, runtime PM).

Yeah, people seem to have that impression though. :(

> If, instead, there was a way to specify a functional dependency at the
> device registration time, it might be used to change the order of
> everything relevant, including probe.  That should help to reduce the
> noise you're referring to.

This links back to the idea of having generic support for pre-probe
actions which is also generally useful (the ability to do things like
power on regulators for devices on enumerable buses so they can be
enumerated as standard).  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

On Sun, Oct 25, 2015 at 02:54:39PM +0100, Rafael J. Wysocki wrote:
> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:

> > There's also the understanding people had that the order things get
> > bound changes the ordering for some of the other cases (perhaps it's a
> > good idea to do that, it seems likely to be sensible?).

> But it really doesn't do that.  Also making it do so doesn't help much
> in the cases where things can happen asynchronously (system
> suspend/resume, runtime PM).

Yeah, people seem to have that impression though. :(

> If, instead, there was a way to specify a functional dependency at the
> device registration time, it might be used to change the order of
> everything relevant, including probe.  That should help to reduce the
> noise you're referring to.

This links back to the idea of having generic support for pre-probe
actions which is also generally useful (the ability to do things like
power on regulators for devices on enumerable buses so they can be
enumerated as standard).  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

On Sun, Oct 25, 2015 at 02:54:39PM +0100, Rafael J. Wysocki wrote:
> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:

> > There's also the understanding people had that the order things get
> > bound changes the ordering for some of the other cases (perhaps it's a
> > good idea to do that, it seems likely to be sensible?).

> But it really doesn't do that.  Also making it do so doesn't help much
> in the cases where things can happen asynchronously (system
> suspend/resume, runtime PM).

Yeah, people seem to have that impression though. :(

> If, instead, there was a way to specify a functional dependency at the
> device registration time, it might be used to change the order of
> everything relevant, including probe.  That should help to reduce the
> noise you're referring to.

This links back to the idea of having generic support for pre-probe
actions which is also generally useful (the ability to do things like
power on regulators for devices on enumerable buses so they can be
enumerated as standard).  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [GIT PULL] On-demand device probing

[Michael Turquette]

Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
> >
> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.
> >
> > Probe deferral is really noisy even if it's working fine on a given
> > system so it's constantly being highlighted to people in a way that
> > other issues aren't if you're not directly having problems.
> >
> > There's also the understanding people had that the order things get
> > bound changes the ordering for some of the other cases (perhaps it's a
> > good idea to do that, it seems likely to be sensible?).
> 
> But it really doesn't do that.  Also making it do so doesn't help much
> in the cases where things can happen asynchronously (system
> suspend/resume, runtime PM).
> 
> If, instead, there was a way to specify a functional dependency at the
> device registration time, it might be used to change the order of
> everything relevant, including probe.  That should help to reduce the
> noise you're referring to.

Taking it a step further, if functional dependencies were understood at
link-time then we could optimize link order as well. There are probably
lots of optimizations if we only made the effort to understand these
dependencies earlier.

Constructing the device/resource dependency graph before the device ever
boots sounds interesting to me.

Regards,
Mike

> 
> If the dependency could only be discovered at the probe time, the
> order of things might be changed in response to letting the driver
> core know about it rather than "just in case", which should be more
> efficient.
> 
> Thanks,
> Rafael

Re: [GIT PULL] On-demand device probing

[Michael Turquette]

Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
> >
> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.
> >
> > Probe deferral is really noisy even if it's working fine on a given
> > system so it's constantly being highlighted to people in a way that
> > other issues aren't if you're not directly having problems.
> >
> > There's also the understanding people had that the order things get
> > bound changes the ordering for some of the other cases (perhaps it's a
> > good idea to do that, it seems likely to be sensible?).
> 
> But it really doesn't do that.  Also making it do so doesn't help much
> in the cases where things can happen asynchronously (system
> suspend/resume, runtime PM).
> 
> If, instead, there was a way to specify a functional dependency at the
> device registration time, it might be used to change the order of
> everything relevant, including probe.  That should help to reduce the
> noise you're referring to.

Taking it a step further, if functional dependencies were understood at
link-time then we could optimize link order as well. There are probably
lots of optimizations if we only made the effort to understand these
dependencies earlier.

Constructing the device/resource dependency graph before the device ever
boots sounds interesting to me.

Regards,
Mike

> 
> If the dependency could only be discovered at the probe time, the
> order of things might be changed in response to letting the driver
> core know about it rather than "just in case", which should be more
> efficient.
> 
> Thanks,
> Rafael

Re: [GIT PULL] On-demand device probing

[Michael Turquette]

Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
> >
> >> Well, I'm not quite sure why exactly everyone is so focused on probing=
 here.
> >
> > Probe deferral is really noisy even if it's working fine on a given
> > system so it's constantly being highlighted to people in a way that
> > other issues aren't if you're not directly having problems.
> >
> > There's also the understanding people had that the order things get
> > bound changes the ordering for some of the other cases (perhaps it's a
> > good idea to do that, it seems likely to be sensible?).
> =

> But it really doesn't do that.  Also making it do so doesn't help much
> in the cases where things can happen asynchronously (system
> suspend/resume, runtime PM).
> =

> If, instead, there was a way to specify a functional dependency at the
> device registration time, it might be used to change the order of
> everything relevant, including probe.  That should help to reduce the
> noise you're referring to.

Taking it a step further, if functional dependencies were understood at
link-time then we could optimize link order as well. There are probably
lots of optimizations if we only made the effort to understand these
dependencies earlier.

Constructing the device/resource dependency graph before the device ever
boots sounds interesting to me.

Regards,
Mike

> =

> If the dependency could only be discovered at the probe time, the
> order of things might be changed in response to letting the driver
> core know about it rather than "just in case", which should be more
> efficient.
> =

> Thanks,
> Rafael

Re: [GIT PULL] On-demand device probing

[Michael Turquette]

Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
> >
> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.
> >
> > Probe deferral is really noisy even if it's working fine on a given
> > system so it's constantly being highlighted to people in a way that
> > other issues aren't if you're not directly having problems.
> >
> > There's also the understanding people had that the order things get
> > bound changes the ordering for some of the other cases (perhaps it's a
> > good idea to do that, it seems likely to be sensible?).
> 
> But it really doesn't do that.  Also making it do so doesn't help much
> in the cases where things can happen asynchronously (system
> suspend/resume, runtime PM).
> 
> If, instead, there was a way to specify a functional dependency at the
> device registration time, it might be used to change the order of
> everything relevant, including probe.  That should help to reduce the
> noise you're referring to.

Taking it a step further, if functional dependencies were understood at
link-time then we could optimize link order as well. There are probably
lots of optimizations if we only made the effort to understand these
dependencies earlier.

Constructing the device/resource dependency graph before the device ever
boots sounds interesting to me.

Regards,
Mike

> 
> If the dependency could only be discovered at the probe time, the
> order of things might be changed in response to letting the driver
> core know about it rather than "just in case", which should be more
> efficient.
> 
> Thanks,
> Rafael

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 26 October 2015 at 11:51, Michael Turquette <mturquette@baylibre.com> wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.
>> >
>> > Probe deferral is really noisy even if it's working fine on a given
>> > system so it's constantly being highlighted to people in a way that
>> > other issues aren't if you're not directly having problems.
>> >
>> > There's also the understanding people had that the order things get
>> > bound changes the ordering for some of the other cases (perhaps it's a
>> > good idea to do that, it seems likely to be sensible?).
>>
>> But it really doesn't do that.  Also making it do so doesn't help much
>> in the cases where things can happen asynchronously (system
>> suspend/resume, runtime PM).
>>
>> If, instead, there was a way to specify a functional dependency at the
>> device registration time, it might be used to change the order of
>> everything relevant, including probe.  That should help to reduce the
>> noise you're referring to.
>
> Taking it a step further, if functional dependencies were understood at
> link-time then we could optimize link order as well. There are probably
> lots of optimizations if we only made the effort to understand these
> dependencies earlier.
>
> Constructing the device/resource dependency graph before the device ever
> boots sounds interesting to me.

Alexander Holler has been looking at that for some time already.

Regards,

Tomeu

> Regards,
> Mike
>
>>
>> If the dependency could only be discovered at the probe time, the
>> order of things might be changed in response to letting the driver
>> core know about it rather than "just in case", which should be more
>> efficient.
>>
>> Thanks,
>> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 26 October 2015 at 11:51, Michael Turquette <mturquette@baylibre.com> wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.
>> >
>> > Probe deferral is really noisy even if it's working fine on a given
>> > system so it's constantly being highlighted to people in a way that
>> > other issues aren't if you're not directly having problems.
>> >
>> > There's also the understanding people had that the order things get
>> > bound changes the ordering for some of the other cases (perhaps it's a
>> > good idea to do that, it seems likely to be sensible?).
>>
>> But it really doesn't do that.  Also making it do so doesn't help much
>> in the cases where things can happen asynchronously (system
>> suspend/resume, runtime PM).
>>
>> If, instead, there was a way to specify a functional dependency at the
>> device registration time, it might be used to change the order of
>> everything relevant, including probe.  That should help to reduce the
>> noise you're referring to.
>
> Taking it a step further, if functional dependencies were understood at
> link-time then we could optimize link order as well. There are probably
> lots of optimizations if we only made the effort to understand these
> dependencies earlier.
>
> Constructing the device/resource dependency graph before the device ever
> boots sounds interesting to me.

Alexander Holler has been looking at that for some time already.

Regards,

Tomeu

> Regards,
> Mike
>
>>
>> If the dependency could only be discovered at the probe time, the
>> order of things might be changed in response to letting the driver
>> core know about it rather than "just in case", which should be more
>> efficient.
>>
>> Thanks,
>> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 26 October 2015 at 11:51, Michael Turquette <mturquette@baylibre.com> wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.
>> >
>> > Probe deferral is really noisy even if it's working fine on a given
>> > system so it's constantly being highlighted to people in a way that
>> > other issues aren't if you're not directly having problems.
>> >
>> > There's also the understanding people had that the order things get
>> > bound changes the ordering for some of the other cases (perhaps it's a
>> > good idea to do that, it seems likely to be sensible?).
>>
>> But it really doesn't do that.  Also making it do so doesn't help much
>> in the cases where things can happen asynchronously (system
>> suspend/resume, runtime PM).
>>
>> If, instead, there was a way to specify a functional dependency at the
>> device registration time, it might be used to change the order of
>> everything relevant, including probe.  That should help to reduce the
>> noise you're referring to.
>
> Taking it a step further, if functional dependencies were understood at
> link-time then we could optimize link order as well. There are probably
> lots of optimizations if we only made the effort to understand these
> dependencies earlier.
>
> Constructing the device/resource dependency graph before the device ever
> boots sounds interesting to me.

Alexander Holler has been looking at that for some time already.

Regards,

Tomeu

> Regards,
> Mike
>
>>
>> If the dependency could only be discovered at the probe time, the
>> order of things might be changed in response to letting the driver
>> core know about it rather than "just in case", which should be more
>> efficient.
>>
>> Thanks,
>> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquette
<mturquette@baylibre.com> wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.
>> >
>> > Probe deferral is really noisy even if it's working fine on a given
>> > system so it's constantly being highlighted to people in a way that
>> > other issues aren't if you're not directly having problems.
>> >
>> > There's also the understanding people had that the order things get
>> > bound changes the ordering for some of the other cases (perhaps it's a
>> > good idea to do that, it seems likely to be sensible?).
>>
>> But it really doesn't do that.  Also making it do so doesn't help much
>> in the cases where things can happen asynchronously (system
>> suspend/resume, runtime PM).
>>
>> If, instead, there was a way to specify a functional dependency at the
>> device registration time, it might be used to change the order of
>> everything relevant, including probe.  That should help to reduce the
>> noise you're referring to.
>
> Taking it a step further, if functional dependencies were understood at
> link-time then we could optimize link order as well. There are probably
> lots of optimizations if we only made the effort to understand these
> dependencies earlier.

Do you mean the kernel link time or something else?

At least in some cases the dependency information won't be known at
that time, so we need a way to record a dependency at the time it
becomes visible to us anyway.

> Constructing the device/resource dependency graph before the device ever
> boots sounds interesting to me.

That's only practical if you build the kernel for a specific device.
If you want a generic binary that can work with multiple different
devices, that graph may very well be different for each of them.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquette
<mturquette@baylibre.com> wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.
>> >
>> > Probe deferral is really noisy even if it's working fine on a given
>> > system so it's constantly being highlighted to people in a way that
>> > other issues aren't if you're not directly having problems.
>> >
>> > There's also the understanding people had that the order things get
>> > bound changes the ordering for some of the other cases (perhaps it's a
>> > good idea to do that, it seems likely to be sensible?).
>>
>> But it really doesn't do that.  Also making it do so doesn't help much
>> in the cases where things can happen asynchronously (system
>> suspend/resume, runtime PM).
>>
>> If, instead, there was a way to specify a functional dependency at the
>> device registration time, it might be used to change the order of
>> everything relevant, including probe.  That should help to reduce the
>> noise you're referring to.
>
> Taking it a step further, if functional dependencies were understood at
> link-time then we could optimize link order as well. There are probably
> lots of optimizations if we only made the effort to understand these
> dependencies earlier.

Do you mean the kernel link time or something else?

At least in some cases the dependency information won't be known at
that time, so we need a way to record a dependency at the time it
becomes visible to us anyway.

> Constructing the device/resource dependency graph before the device ever
> boots sounds interesting to me.

That's only practical if you build the kernel for a specific device.
If you want a generic binary that can work with multiple different
devices, that graph may very well be different for each of them.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquette
<mturquette@baylibre.com> wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I'm not quite sure why exactly everyone is so focused on probing here.
>> >
>> > Probe deferral is really noisy even if it's working fine on a given
>> > system so it's constantly being highlighted to people in a way that
>> > other issues aren't if you're not directly having problems.
>> >
>> > There's also the understanding people had that the order things get
>> > bound changes the ordering for some of the other cases (perhaps it's a
>> > good idea to do that, it seems likely to be sensible?).
>>
>> But it really doesn't do that.  Also making it do so doesn't help much
>> in the cases where things can happen asynchronously (system
>> suspend/resume, runtime PM).
>>
>> If, instead, there was a way to specify a functional dependency at the
>> device registration time, it might be used to change the order of
>> everything relevant, including probe.  That should help to reduce the
>> noise you're referring to.
>
> Taking it a step further, if functional dependencies were understood at
> link-time then we could optimize link order as well. There are probably
> lots of optimizations if we only made the effort to understand these
> dependencies earlier.

Do you mean the kernel link time or something else?

At least in some cases the dependency information won't be known at
that time, so we need a way to record a dependency at the time it
becomes visible to us anyway.

> Constructing the device/resource dependency graph before the device ever
> boots sounds interesting to me.

That's only practical if you build the kernel for a specific device.
If you want a generic binary that can work with multiple different
devices, that graph may very well be different for each of them.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 12:04:05 PM Alan Stern wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
> 
> > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> > 
> > > Furthermore, that applies only to devices that use synchronous suspend.  
> > > Async suspend is becoming common, and there the only restrictions are 
> > > parent-child relations plus whatever explicit requirements that drivers 
> > > impose by calling device_pm_wait_for_dev().
> > 
> > Hrm, this is the first I'd noticed that feature though I see the initial
> > commit dates from January.
> 
> Async suspend and device_pm_wait_for_dev() were added in January 2010, 
> not 2015!
> 
> >  It looks like most of the users are PCs at
> > the minute but we should be using it more widely for embedded things,
> > there's definitely some cases I'm aware of where it will allow us to
> > remove some open coding.
> > 
> > It does seem like we want to be feeding dependency information we
> > discover for probing way into the suspend dependencies...
> 
> Rafael has been thinking about a way to do this systematically.  
> Nothing concrete has emerged yet.

Well, good point. :-)

I've been kind of struggling with finding time to work on the patches lately
and some aspects of the design are still not finalized.  It seems, though, that
it can be beneficial to discuss the approach in general, so let me start a new
thread for that.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 12:04:05 PM Alan Stern wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
> 
> > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> > 
> > > Furthermore, that applies only to devices that use synchronous suspend.  
> > > Async suspend is becoming common, and there the only restrictions are 
> > > parent-child relations plus whatever explicit requirements that drivers 
> > > impose by calling device_pm_wait_for_dev().
> > 
> > Hrm, this is the first I'd noticed that feature though I see the initial
> > commit dates from January.
> 
> Async suspend and device_pm_wait_for_dev() were added in January 2010, 
> not 2015!
> 
> >  It looks like most of the users are PCs at
> > the minute but we should be using it more widely for embedded things,
> > there's definitely some cases I'm aware of where it will allow us to
> > remove some open coding.
> > 
> > It does seem like we want to be feeding dependency information we
> > discover for probing way into the suspend dependencies...
> 
> Rafael has been thinking about a way to do this systematically.  
> Nothing concrete has emerged yet.

Well, good point. :-)

I've been kind of struggling with finding time to work on the patches lately
and some aspects of the design are still not finalized.  It seems, though, that
it can be beneficial to discuss the approach in general, so let me start a new
thread for that.

Thanks,
Rafael

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 12:04:05 PM Alan Stern wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
> 
> > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> > 
> > > Furthermore, that applies only to devices that use synchronous suspend.  
> > > Async suspend is becoming common, and there the only restrictions are 
> > > parent-child relations plus whatever explicit requirements that drivers 
> > > impose by calling device_pm_wait_for_dev().
> > 
> > Hrm, this is the first I'd noticed that feature though I see the initial
> > commit dates from January.
> 
> Async suspend and device_pm_wait_for_dev() were added in January 2010, 
> not 2015!
> 
> >  It looks like most of the users are PCs at
> > the minute but we should be using it more widely for embedded things,
> > there's definitely some cases I'm aware of where it will allow us to
> > remove some open coding.
> > 
> > It does seem like we want to be feeding dependency information we
> > discover for probing way into the suspend dependencies...
> 
> Rafael has been thinking about a way to do this systematically.  
> Nothing concrete has emerged yet.

Well, good point. :-)

I've been kind of struggling with finding time to work on the patches lately
and some aspects of the design are still not finalized.  It seems, though, that
it can be beneficial to discuss the approach in general, so let me start a new
thread for that.

Thanks,
Rafael