mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Barebox List <barebox@lists.infradead.org>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH v2 00/18] PCIe support for i.MX7
Date: Tue, 15 Jan 2019 08:22:31 +0100	[thread overview]
Message-ID: <20190115072231.cn7edbxsskx63ces@pengutronix.de> (raw)
In-Reply-To: <CAHQ1cqGD9sTWP4yS2OFDuXAdQaC5L6JnbyQPd71pO49v2qBxYg@mail.gmail.com>

On Sat, Jan 12, 2019 at 11:49:19AM -0800, Andrey Smirnov wrote:
> On Sat, Jan 12, 2019 at 2:48 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > Hi Andrey.
> >
> > > Feedback is welcome!
> >
> > I have looked through the patches - and nothing jumped at me.
> > A few places could use a newline but not worth a re-spin.
> >
> > I personal dislike filenames like "helpers.c" but thats pure bikeshedding.
> >
> 
> One of my goals was to keep things as close to how they are in Linux
> as possible. That's how that file is called there, so you might have
> to take it with Mark Brown if you want to change that.
> 
> > Looks good with the simple regulator support, which most likely will prove
> > useful later also for other drivers.
> > I hope we do not need deferred probe much...
> >
> > With deferred probe ported from the kernel, I wonder
> > how far we are from porting the devm_* functionlity too.
> > Not the I think this will share code with deferred probe,
> > just that this is another nice kernel idiom we could
> > benefit from in barebox.
> >
> 
> Just to clarify, deferred probe was already a part of Barebox for a
> while, the patches in this series only change the fact that Barebox
> core now has a chance to "give up" on deferred device and declare it
> as non-existent.
> 
> As for devm_* functions, not far at all. I don't think it would be
> difficult to port and I've been meaning to do that for a while, just
> never had an opportunity to do it so far.

There's another idea I'd like to explore before we go deeper into probe
deferral.

Whenever a framework needs a device probed from some device tree node it
could call a of_ensure_probed(struct device_node *np) function. This
function would then go back into the driver core and probe the device
behind this device node.

This would require some restructuring of the driver core, like for
example all devices and drivers have to be registered before they are
actually probed. This of course goes against non device tree based
builds which have a hand crafted initcall order to resolve dependencies.

Maybe this is a crazy idea, but at least I'd like to know why this
doesn't work ;)

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  parent reply	other threads:[~2019-01-15  7:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-12  5:55 Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 01/18] regulator: Convert drivers to use struct regulator_desc Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 02/18] regulator: Port basic regmap regulator functions Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 03/18] regulator: Add support for setting regulator's voltage Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 04/18] base: driver: Drop redundant list_empty() check Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 05/18] base: Port driver_deferred_probe_check_state() from Linux Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 06/18] regulator: Add primitive support for deferred probe Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 07/18] regulator: Port ANATOP driver from Linux Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 08/18] drivers: base: Port power management code " Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 09/18] soc: imx: Add GPCv2 power gating driver Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 10/18] reset: Add i.MX7 SRC reset driver Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 11/18] reset: Mark local functions as static Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 12/18] PCI: imx6: Add code to support i.MX7D Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 13/18] PCI: imx6: Allow probe deferral by reset GPIO Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 14/18] PCI: imx6: Do not wait for speed change on i.MX7 Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 15/18] PCI: imx6: Do not switch speed if Gen2 is disabled Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 16/18] PCI: imx6: Fix spelling mistake: "contol" -> "control" Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 17/18] PCI: imx6: Drop unnecessary root_bus_nr setting Andrey Smirnov
2019-01-12  5:55 ` [PATCH v2 18/18] PCI: imx6: Port imx6_pcie_ltssm_enable() Andrey Smirnov
2019-01-12 10:48 ` [PATCH v2 00/18] PCIe support for i.MX7 Sam Ravnborg
2019-01-12 19:49   ` Andrey Smirnov
2019-01-12 20:10     ` Sam Ravnborg
2019-01-15  7:22     ` Sascha Hauer [this message]
2019-01-15 20:16       ` Andrey Smirnov

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20190115072231.cn7edbxsskx63ces@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=andrew.smirnov@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=sam@ravnborg.org \
    /path/to/YOUR_REPLY

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

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