Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2)

[Geert Uytterhoeven <geert@linux-m68k.org>]

On Wed, Jul 27, 2016 at 8:03 PM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, Jul 27, 2016 at 07:58:29PM +0200, Luis R. Rodriguez wrote:
>> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
>> > > to help enable asynchronous probe, however for built-in devices this requires
>> > > very specific platform knowledge otherwise using async probe will blow up
>> > > your kernel -- if you get it right though, using async probe can help with
>
>> > I'm not sure what specific platform knowledge you're thinking of here?
>> > We have coverage for most things in the form of deferred probe (messy
>> > though it is).
>
>> Deferred probe is a complete a hack and sub-optimal. Being able to address
>
> Sure, I don't think anyone disagrees on that but it does mean we don't
> actually blow up easily like we used to - it's messy but it does get
> there safely.  I was specifically querying your statement that things
> would blow up.

Some drivers/subsystems don't support deferred probing yet. Such failures
usually don't blow up, but cause subtle malfunctioning.

In the specific case I encountered, an Ethernet phy couldn't get its interrupt
in of_mdiobus_register_phy(), as the (non-primary) irqchip hadn't been probed
yet. It didn't really blow up, though, as the phy driver fell back to polling.

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