On Friday, July 31, 2015 11:39:07 AM Viresh Kumar wrote:
> On 30-07-15, 20:53, Rafael J. Wysocki wrote:
> > Well, on ACPI systems we actually do probe CPU devices. We have a processor
> > driver there that binds to CPU devices and the cpufreq driver is just a
> > frontend to that.
>
> Hmm, maybe
On 30-07-15, 20:53, Rafael J. Wysocki wrote:
> Well, on ACPI systems we actually do probe CPU devices. We have a processor
> driver there that binds to CPU devices and the cpufreq driver is just a
> frontend to that.
Hmm, maybe I need to look at that in detail..
> So question is what prevents DT
On Thursday, July 30, 2015 09:14:31 AM Viresh Kumar wrote:
> On 30-07-15, 01:29, Rafael J. Wysocki wrote:
> > > > There is a small problem with it that I've already pointed out to
> > > > Viresh.
> > > >
> > > > Namely, while changing subsys_interface_(un)register() to handle return
> > > > value
On 30-07-15, 01:29, Rafael J. Wysocki wrote:
> > > There is a small problem with it that I've already pointed out to Viresh.
> > >
> > > Namely, while changing subsys_interface_(un)register() to handle return
> > > values from ->add_dev(), it doesn't do the same thing in
> > > bus_probe_device()
On 29-07-15, 14:19, Greg KH wrote:
> I don't see how this is a stable bug fix, what is resolved by it that
> doesn't work today? Is there some code that is expecting this
> functionality that has never been present?
>
> I'll go queue it up, but I don't think it is -stable material, but feel
> fre
On Thu, Jul 30, 2015 at 01:29:01AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 29, 2015 03:37:43 PM Greg KH wrote:
> > On Thu, Jul 30, 2015 at 01:01:21AM +0200, Rafael J. Wysocki wrote:
> > > On Wednesday, July 29, 2015 02:19:16 PM Greg KH wrote:
> > > > On Fri, Jun 26, 2015 at 02:32:47PM
On Wednesday, July 29, 2015 03:37:43 PM Greg KH wrote:
> On Thu, Jul 30, 2015 at 01:01:21AM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, July 29, 2015 02:19:16 PM Greg KH wrote:
> > > On Fri, Jun 26, 2015 at 02:32:47PM +0530, Viresh Kumar wrote:
> > > > ->add_dev() may fail and the error retur
On Thu, Jul 30, 2015 at 01:01:21AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, July 29, 2015 02:19:16 PM Greg KH wrote:
> > On Fri, Jun 26, 2015 at 02:32:47PM +0530, Viresh Kumar wrote:
> > > ->add_dev() may fail and the error returned from it can be useful for
> > > the caller.
> > >
> > > Fo
On Wednesday, July 29, 2015 02:19:16 PM Greg KH wrote:
> On Fri, Jun 26, 2015 at 02:32:47PM +0530, Viresh Kumar wrote:
> > ->add_dev() may fail and the error returned from it can be useful for
> > the caller.
> >
> > For example, if some of the resources aren't ready yet and -EPROBE_DEFER
> > is r
On Fri, Jun 26, 2015 at 02:32:47PM +0530, Viresh Kumar wrote:
> ->add_dev() may fail and the error returned from it can be useful for
> the caller.
>
> For example, if some of the resources aren't ready yet and -EPROBE_DEFER
> is returned from ->add_dev(), then the owner of 'struct
> subsys_interf
->add_dev() may fail and the error returned from it can be useful for
the caller.
For example, if some of the resources aren't ready yet and -EPROBE_DEFER
is returned from ->add_dev(), then the owner of 'struct
subsys_interface' may want to try probing again at a later point of
time. And that requ
11 matches
Mail list logo
