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 the
On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquette
wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown 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 s
On 26 October 2015 at 11:51, Michael Turquette wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown 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 foc
Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown 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
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 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
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
On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown 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 consta
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 ar
On Thu, Oct 22, 2015 at 8:53 PM, Frank Rowand 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
On Friday, October 23, 2015 11:34:34 AM Rob Herring wrote:
> On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird wrote:
> > On 10/22/2015 11:53 AM, Frank Rowand wrote:
> >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> >>>
> >>>
> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> >>
On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird wrote:
> On 10/22/2015 11:53 AM, Frank Rowand wrote:
>> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>>
>>>
>>> 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
>>
On 10/22/2015 11:53 AM, Frank Rowand wrote:
> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>>
>>
>> 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
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:
>>>
>>>
>>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
But that's moot currently because Greg believes that
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. Someo
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
On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote:
> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> >
> >
> > 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 cou
On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
>
>
> 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 beco
On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote:
>
>
> 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
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
On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> On 21 October 2015 at 23:50, Frank Rowand wrote:
> > On 10/21/2015 2:12 PM, Rob Herring wrote:
> >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand
> >> wrote:
> >>> On 10/21/2015 9:27 AM, Mark Brown wrote:
> On Wed, Oct 21, 2015
On 22 October 2015 at 02:54, Rafael J. Wysocki wrote:
> On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
>> On 20 October 2015 at 18:04, Alan Stern wrote:
>> > On Tue, 20 Oct 2015, Mark Brown wrote:
>> >
>> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>> >>
>> >> > F
On 21 October 2015 at 23:50, Frank Rowand wrote:
> On 10/21/2015 2:12 PM, Rob Herring wrote:
>> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand 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 V
On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
> On 20 October 2015 at 18:04, 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 s
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 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
> >> wrote:
> >> > ACPI uses pl
On 10/21/2015 2:12 PM, Rob Herring wrote:
> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand 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 th
On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand 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
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 consu
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, impro
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 ac
On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> On 18 October 2015 at 21:53, 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
Hi Rafael,
On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki 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
>> wrote:
>> > ACPI uses platform devices too. In fact, ACPI device objects are
>> > enumerated as
>> > plat
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
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
On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki 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
> >> wrote:
> >> > On Monday, October 19, 2015 10:58:25 A
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 proposi
On Tue, 20 Oct 2015, Tomeu Vizoso wrote:
> On 20 October 2015 at 18:04, 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.
> >> > Asyn
On 20 October 2015 at 18:04, 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 restric
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
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
> wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - possibly augmenting that with reports
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 ca
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
On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki 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
>> wrote:
>> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
>> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woo
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
On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki wrote:
> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse
> >> wrote:
> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark
On Tue, Oct 20, 2015 at 3:39 AM, Russell King - ARM Linux
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
>>
On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki wrote:
> On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
>> On Mon, Oct 19, 2015 at 10:29 AM, 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
On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 10:29 AM, 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 pl
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 fwnod
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
>
On Sat, Oct 17, 2015 at 8:19 AM, Rob Herring wrote:
> On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson 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
>> wrote:
>>> Tomeu Vizoso (20):
>>> dr
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
> wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - possibly augmenting that with reports
Hi Russell,
On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
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
>
On Mon, Oct 19, 2015 at 10:29 AM, 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
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.
> >
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 pr
On Mon, Oct 19, 2015 at 05:00:54PM +0200, Tomeu Vizoso wrote:
> On 19 October 2015 at 16:30, Russell King - ARM Linux
> 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 doze
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
On 19 October 2015 at 16:30, Russell King - ARM Linux
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
>> wrote:
>> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote:
>> >> ... If a device is available and
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
On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote:
> On 19 October 2015 at 15:18, Russell King - ARM Linux
> 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 dep
On 19 October 2015 at 15:18, Russell King - ARM Linux
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
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. Current
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 spec
On Mon, Oct 19, 2015 at 4:44 AM, 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, Gr
On 18 October 2015 at 21:53, 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 a
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 gratuit
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:50P
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 li
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 pr
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 makin
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,
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
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
> 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
> >> wrote:
> >> > On Sat, Oct 17, 2015 at 01:54:43PM -
On Sat, Oct 17, 2015 at 3:04 PM, Noralf Trønnes wrote:
>
> Den 17.10.2015 20:45, skrev Rob Clark:
>>
>> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
>> 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
>
On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman
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
>> wrote:
>> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
>> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kro
Den 17.10.2015 20:45, skrev Rob Clark:
On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
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
wrote:
I'm guessing the time is a matter of probing and undoing the probes
rather
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
> 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
> >> wrote:
> >> >> I'm guessing the time is a matter
On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman
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
>> wrote:
>> >> I'm guessing the time is a matter of probing and undoing the probes
>> >> rather than slow h/w. We could
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
> 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 de
On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
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,
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
> 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
> >> wrote:
> >> > On Wed, Oct 14, 2015 at 10:34:0
On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman
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
>> wrote:
>> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
>> >> Hi Rob,
>> >>
>> >> here is the pull
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
> 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
On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson 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
> wrote:
>> Tomeu Vizoso (20):
>> driver core: handle -EPROBE_DEFER from bus_type.match()
>
> The m
On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman
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 6ff33f390
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
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
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
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 6ff33f3902c3b1c5d0db6b1e2c70b6d76
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)?
signature.asc
Description: PGP signature
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.collabor
90 matches
Mail list logo
