Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1186224 > unrolled thread

Re: [PATCH v2 01/12] device: property: delay device-driver matches

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 01/12] device: property: delay device-driver matches Mark Brown <broonie@kernel.org> - 2015-07-16 22:30 +0200
    Re: [PATCH v2 01/12] device: property: delay device-driver matches "Rafael J. Wysocki" <rafael@kernel.org> - 2015-07-17 01:50 +0200
      Re: [PATCH v2 01/12] device: property: delay device-driver matches Mark Brown <broonie@kernel.org> - 2015-07-17 02:10 +0200

#1186224 — Re: [PATCH v2 01/12] device: property: delay device-driver matches

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jul 01, 2015 at 11:40:56AM +0200, Tomeu Vizoso wrote:

> Delay matches of platform devices until late_initcall, when we are sure
> that all built-in drivers have been registered already. This is needed
> to prevent deferred probes because of some dependencies' drivers not
> having registered yet.

I have to say I'm still not 100% clear that special casing platform
devices makes sense here - I can see that platform devices are usually
the first devices to instantiate but there are other kinds of devices
and it's not obvious what the benefit of specifically picking out
platform devices as opposed to just deferring all devices is.

[toc] | [next] | [standalone]

#1186331

Hi Mark,

On Thu, Jul 16, 2015 at 10:23 PM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, Jul 01, 2015 at 11:40:56AM +0200, Tomeu Vizoso wrote:
>
>> Delay matches of platform devices until late_initcall, when we are sure
>> that all built-in drivers have been registered already. This is needed
>> to prevent deferred probes because of some dependencies' drivers not
>> having registered yet.
>
> I have to say I'm still not 100% clear that special casing platform
> devices makes sense here - I can see that platform devices are usually
> the first devices to instantiate but there are other kinds of devices
> and it's not obvious what the benefit of specifically picking out
> platform devices as opposed to just deferring all devices is.

Some existing devices cannot be deferred without redesigning things quite a bit.

What I was talking about, though, was to use an opt-in mechanism for
that which could be set for all platform devices, for example, by
default, but it might be set for other bus types too if that's useful.

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/

[toc] | [prev] | [next] | [standalone]

#1186337

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jul 17, 2015 at 01:41:16AM +0200, Rafael J. Wysocki wrote:
> On Thu, Jul 16, 2015 at 10:23 PM, Mark Brown <broonie@kernel.org> wrote:
> > On Wed, Jul 01, 2015 at 11:40:56AM +0200, Tomeu Vizoso wrote:

> > I have to say I'm still not 100% clear that special casing platform
> > devices makes sense here - I can see that platform devices are usually
> > the first devices to instantiate but there are other kinds of devices
> > and it's not obvious what the benefit of specifically picking out
> > platform devices as opposed to just deferring all devices is.

> Some existing devices cannot be deferred without redesigning things quite a bit.

OK, that should go in the changelog then - right now it's just a bit
obtuse why we're doing this (and as you say it's a bit awkward).  Now
you mention this I'm thinking that some of the affected devices might be
platform devices on some systems, IOMMUs spring to mind for example...
they're one of the main bits of the system I'm aware of that still rely
on probe ordering and they do tend to be platform devices.

> What I was talking about, though, was to use an opt-in mechanism for
> that which could be set for all platform devices, for example, by
> default, but it might be set for other bus types too if that's useful.

Sure, I got that and do agree with you that a mechanism like you suggest
would be good.  I just wasn't clear why we were targetting platform
devices in the first place.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web