On 30 October 2015 at 23:52, Greg Kroah-Hartman
wrote:
> On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
>> My idea is to represent a supplier-consumer dependency between devices (or
>> more precisely between device+driver combos) as a "link" object containing
>> pointers to
On 30 October 2015 at 23:52, Greg Kroah-Hartman
wrote:
> On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
>> My idea is to represent a supplier-consumer dependency between devices (or
>> more precisely between device+driver combos) as a "link" object
Hi,
Sorry for late response.
On 11/24/2015 05:28 PM, Rafael J. Wysocki wrote:
> On Tuesday, November 24, 2015 03:57:09 PM Andrzej Hajda wrote:
>> On 11/19/2015 11:04 PM, Rafael J. Wysocki wrote:
>>> On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote:
On 11/18/2015 03:17 AM,
Hi,
Sorry for late response.
On 11/24/2015 05:28 PM, Rafael J. Wysocki wrote:
> On Tuesday, November 24, 2015 03:57:09 PM Andrzej Hajda wrote:
>> On 11/19/2015 11:04 PM, Rafael J. Wysocki wrote:
>>> On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote:
On 11/18/2015 03:17 AM,
On Tuesday, November 24, 2015 03:57:09 PM Andrzej Hajda wrote:
> On 11/19/2015 11:04 PM, Rafael J. Wysocki wrote:
> > On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote:
> >> On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote:
> >>> On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda
On 11/19/2015 11:04 PM, Rafael J. Wysocki wrote:
> On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote:
>> On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote:
>>> On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote:
Hi Rafael,
> [cut]
>
>>> So the operations that need
On 11/21/2015 03:04 PM, Mark Brown wrote:
> On Thu, Nov 19, 2015 at 07:50:45AM +0100, Andrzej Hajda wrote:
>> On 11/17/2015 02:55 PM, Mark Brown wrote:
>>> This is going to be really common but I'm not sure I see a problem with
>>> it in terms of what Raphael is proposing - could you go into more
On 11/19/2015 11:04 PM, Rafael J. Wysocki wrote:
> On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote:
>> On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote:
>>> On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote:
Hi Rafael,
> [cut]
>
>>> So the operations that need
On 11/21/2015 03:04 PM, Mark Brown wrote:
> On Thu, Nov 19, 2015 at 07:50:45AM +0100, Andrzej Hajda wrote:
>> On 11/17/2015 02:55 PM, Mark Brown wrote:
>>> This is going to be really common but I'm not sure I see a problem with
>>> it in terms of what Raphael is proposing - could you go into more
On Tuesday, November 24, 2015 03:57:09 PM Andrzej Hajda wrote:
> On 11/19/2015 11:04 PM, Rafael J. Wysocki wrote:
> > On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote:
> >> On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote:
> >>> On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda
On Thu, Nov 19, 2015 at 07:50:45AM +0100, Andrzej Hajda wrote:
> On 11/17/2015 02:55 PM, Mark Brown wrote:
> > This is going to be really common but I'm not sure I see a problem with
> > it in terms of what Raphael is proposing - could you go into more detail
> > on the problem you see here?
>
On Thu, Nov 19, 2015 at 02:18:59PM +0100, Thierry Reding wrote:
> On Tue, Nov 17, 2015 at 01:55:49PM +, Mark Brown wrote:
> > On Tue, Nov 17, 2015 at 01:49:17PM +0100, Andrzej Hajda wrote:
> > > On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
> > > this scenario:
> > > - many clock
On Thu, Nov 19, 2015 at 07:50:45AM +0100, Andrzej Hajda wrote:
> On 11/17/2015 02:55 PM, Mark Brown wrote:
> > This is going to be really common but I'm not sure I see a problem with
> > it in terms of what Raphael is proposing - could you go into more detail
> > on the problem you see here?
>
On Thu, Nov 19, 2015 at 02:18:59PM +0100, Thierry Reding wrote:
> On Tue, Nov 17, 2015 at 01:55:49PM +, Mark Brown wrote:
> > On Tue, Nov 17, 2015 at 01:49:17PM +0100, Andrzej Hajda wrote:
> > > On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
> > > this scenario:
> > > - many clock
On Thursday, November 19, 2015 11:04:00 PM Rafael J. Wysocki wrote:
> On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote:
> > On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote:
> > > On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote:
> > >> Hi Rafael,
> > >>
>
> [cut]
>
> >
On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote:
> On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote:
> > On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote:
> >> Hi Rafael,
> >>
[cut]
> > So the operations that need to be taken care of are:
> > - Probe (suppliers need to
On Tue, Nov 17, 2015 at 01:55:49PM +, Mark Brown wrote:
> On Tue, Nov 17, 2015 at 01:49:17PM +0100, Andrzej Hajda wrote:
> > On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
>
> > this scenario:
> > - many clock providers, irq domains are not provided by devices,
>
> That seems like
On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote:
> On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote:
>> Hi Rafael,
>>
>> Please forgive me late reply, but I have missed this thread before.
>>
>> On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
>>> Hi All,
>>>
>>> As discussed in the
On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote:
> On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote:
>> Hi Rafael,
>>
>> Please forgive me late reply, but I have missed this thread before.
>>
>> On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
>>> Hi All,
>>>
>>> As discussed in the
On Thursday, November 19, 2015 11:04:00 PM Rafael J. Wysocki wrote:
> On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote:
> > On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote:
> > > On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote:
> > >> Hi Rafael,
> > >>
>
> [cut]
>
> >
On Thursday, November 19, 2015 10:08:43 AM Andrzej Hajda wrote:
> On 11/18/2015 03:17 AM, Rafael J. Wysocki wrote:
> > On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote:
> >> Hi Rafael,
> >>
[cut]
> > So the operations that need to be taken care of are:
> > - Probe (suppliers need to
On Tue, Nov 17, 2015 at 01:55:49PM +, Mark Brown wrote:
> On Tue, Nov 17, 2015 at 01:49:17PM +0100, Andrzej Hajda wrote:
> > On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
>
> > this scenario:
> > - many clock providers, irq domains are not provided by devices,
>
> That seems like
On 11/17/2015 02:55 PM, Mark Brown wrote:
> On Tue, Nov 17, 2015 at 01:49:17PM +0100, Andrzej Hajda wrote:
>
> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80 columns. Doing this makes your messages much
> easier to read and reply to.
>
>> On
On 11/17/2015 02:55 PM, Mark Brown wrote:
> On Tue, Nov 17, 2015 at 01:49:17PM +0100, Andrzej Hajda wrote:
>
> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80 columns. Doing this makes your messages much
> easier to read and reply to.
>
>> On
On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote:
> Hi Rafael,
>
> Please forgive me late reply, but I have missed this thread before.
>
> On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
> > Hi All,
> >
> > As discussed in the recent "On-demand device probing" thread and in a
On Tue, Nov 17, 2015 at 03:31:29PM -0500, Alan Stern wrote:
> Also, there's a real problem that needs to be solved concerning how
> resources are identified in the absence of DT (or ACPI or something
> similar).
So long as we can add new dependencies at probe time we should always be
able to
On Tue, 17 Nov 2015, Andrzej Hajda wrote:
> > and I'd like the driver core to track them and act on them in certain cases
> > where they matter. The argument for doing that in the driver core is that
> > there are quite a few distinct use cases related to that, they are
> > relatively
> > hard
On Tue, Nov 17, 2015 at 01:49:17PM +0100, Andrzej Hajda wrote:
Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns. Doing this makes your messages much
easier to read and reply to.
> On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
> this
Hi Rafael,
It is just re-send of the previous message with fixed e-mail.
Please forgive me late reply, but I have missed this thread before.
On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
> Hi All,
>
> As discussed in the recent "On-demand device probing" thread and in a Kernel
> Summit
Hi Rafael,
Please forgive me late reply, but I have missed this thread before.
On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
> Hi All,
>
> As discussed in the recent "On-demand device probing" thread and in a Kernel
> Summit session earlier today, there is a problem with handling cases where
Hi Rafael,
Please forgive me late reply, but I have missed this thread before.
On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
> Hi All,
>
> As discussed in the recent "On-demand device probing" thread and in a Kernel
> Summit session earlier today, there is a problem with handling cases where
Hi Rafael,
It is just re-send of the previous message with fixed e-mail.
Please forgive me late reply, but I have missed this thread before.
On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
> Hi All,
>
> As discussed in the recent "On-demand device probing" thread and in a Kernel
> Summit
On Tue, Nov 17, 2015 at 01:49:17PM +0100, Andrzej Hajda wrote:
Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns. Doing this makes your messages much
easier to read and reply to.
> On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
> this
On Tue, Nov 17, 2015 at 03:31:29PM -0500, Alan Stern wrote:
> Also, there's a real problem that needs to be solved concerning how
> resources are identified in the absence of DT (or ACPI or something
> similar).
So long as we can add new dependencies at probe time we should always be
able to
On Tuesday, November 17, 2015 01:44:59 PM Andrzej Hajda wrote:
> Hi Rafael,
>
> Please forgive me late reply, but I have missed this thread before.
>
> On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote:
> > Hi All,
> >
> > As discussed in the recent "On-demand device probing" thread and in a
On Tue, 17 Nov 2015, Andrzej Hajda wrote:
> > and I'd like the driver core to track them and act on them in certain cases
> > where they matter. The argument for doing that in the driver core is that
> > there are quite a few distinct use cases related to that, they are
> > relatively
> > hard
On Monday, November 09, 2015 01:32:04 PM Thierry Reding wrote:
> On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
> [...]
> > There's a question about what if the supplier device is being unbound before
> > the consumer one (for example, as a result of a hotplug event). My
On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
[...]
> There's a question about what if the supplier device is being unbound before
> the consumer one (for example, as a result of a hotplug event). My current
> view on that is that the consumer needs to be force-unbound in
On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
[...]
> There's a question about what if the supplier device is being unbound before
> the consumer one (for example, as a result of a hotplug event). My current
> view on that is that the consumer needs to be force-unbound in
On Monday, November 09, 2015 01:32:04 PM Thierry Reding wrote:
> On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
> [...]
> > There's a question about what if the supplier device is being unbound before
> > the consumer one (for example, as a result of a hotplug event). My
On Sat, 31 Oct 2015, Rafael J. Wysocki wrote:
> > One possible approach is to have a "wait_for_driver" flag, along with a
> > timeout value (or perhaps using a fixed timeout value). When a
> > dependency gets registered with this flag set, the function call
> > wouldn't return until the target
On Sat, 31 Oct 2015, Rafael J. Wysocki wrote:
> > One possible approach is to have a "wait_for_driver" flag, along with a
> > timeout value (or perhaps using a fixed timeout value). When a
> > dependency gets registered with this flag set, the function call
> > wouldn't return until the target
On Sat, Oct 31, 2015 at 03:13:09AM +0100, Rafael J. Wysocki wrote:
> On Thursday, October 29, 2015 09:15:09 AM Mark Brown wrote:
> > This seems like a good plan to me however I am concerned that only
> > allowing links to be created at device registration time will prove
> > restrictive - it
On Thursday, October 29, 2015 10:31:08 AM Alan Stern wrote:
> Good grief, don't you guys ever trim unwanted material from your
> emails? I had to erase more than 4 screens worth of useless stuff
> before getting to the relevant portions.
>
> On Thu, 29 Oct 2015, Tomeu Vizoso wrote:
>
> > >>
On Thursday, October 29, 2015 09:15:09 AM Mark Brown wrote:
> On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
>
> > So, the question to everybody is whether or not this sounds reasonable or
> > there
> > are concerns about it and if so what they are. At this point I mostly
On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
> My idea is to represent a supplier-consumer dependency between devices (or
> more precisely between device+driver combos) as a "link" object containing
> pointers to the devices in question, a list node for each of them and some
On Tue, Oct 27, 2015 at 4:24 PM, Rafael J. Wysocki wrote:
> My idea is to represent a supplier-consumer dependency between devices (or
> more precisely between device+driver combos) as a "link" object containing
> pointers to the devices in question, a list node for each of them and some
>
On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
> My idea is to represent a supplier-consumer dependency between devices (or
> more precisely between device+driver combos) as a "link" object containing
> pointers to the devices in question, a list node for each of them and some
On Tue, Oct 27, 2015 at 4:24 PM, Rafael J. Wysocki wrote:
> My idea is to represent a supplier-consumer dependency between devices (or
> more precisely between device+driver combos) as a "link" object containing
> pointers to the devices in question, a list node for each of
On Thursday, October 29, 2015 09:15:09 AM Mark Brown wrote:
> On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
>
> > So, the question to everybody is whether or not this sounds reasonable or
> > there
> > are concerns about it and if so what they are. At this point I mostly
On Thursday, October 29, 2015 10:31:08 AM Alan Stern wrote:
> Good grief, don't you guys ever trim unwanted material from your
> emails? I had to erase more than 4 screens worth of useless stuff
> before getting to the relevant portions.
>
> On Thu, 29 Oct 2015, Tomeu Vizoso wrote:
>
> > >>
On Sat, Oct 31, 2015 at 03:13:09AM +0100, Rafael J. Wysocki wrote:
> On Thursday, October 29, 2015 09:15:09 AM Mark Brown wrote:
> > This seems like a good plan to me however I am concerned that only
> > allowing links to be created at device registration time will prove
> > restrictive - it
Good grief, don't you guys ever trim unwanted material from your
emails? I had to erase more than 4 screens worth of useless stuff
before getting to the relevant portions.
On Thu, 29 Oct 2015, Tomeu Vizoso wrote:
> >> Also, have you considered that not only drivers request resources? For
> >>
On 28 October 2015 at 16:54, Rafael J. Wysocki wrote:
> On Wednesday, October 28, 2015 03:26:14 PM Tomeu Vizoso wrote:
>> On 28 October 2015 at 03:15, Rafael J. Wysocki wrote:
>> > On Tuesday, October 27, 2015 04:20:51 PM Tomeu Vizoso wrote:
>> >> On 27 October 2015 at 16:24, Rafael J. Wysocki
On 28 October 2015 at 16:54, Rafael J. Wysocki wrote:
> On Wednesday, October 28, 2015 03:26:14 PM Tomeu Vizoso wrote:
>> On 28 October 2015 at 03:15, Rafael J. Wysocki wrote:
>> > On Tuesday, October 27, 2015 04:20:51 PM Tomeu Vizoso wrote:
>> >> On 27
Good grief, don't you guys ever trim unwanted material from your
emails? I had to erase more than 4 screens worth of useless stuff
before getting to the relevant portions.
On Thu, 29 Oct 2015, Tomeu Vizoso wrote:
> >> Also, have you considered that not only drivers request resources? For
> >>
On Wed, Oct 28, 2015 at 04:54:04PM +0100, Rafael J. Wysocki wrote:
> Information that is already available at the device registration time should
> be used at that time or it makes things harder to follow.
> But that really is a tradeoff. If collecting that information requires too
> much
On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
> So, the question to everybody is whether or not this sounds reasonable or
> there
> are concerns about it and if so what they are. At this point I mostly need to
> know if I'm not overlooking anything fundamental at the
On Wednesday, October 28, 2015 03:26:14 PM Tomeu Vizoso wrote:
> On 28 October 2015 at 03:15, Rafael J. Wysocki wrote:
> > On Tuesday, October 27, 2015 04:20:51 PM Tomeu Vizoso wrote:
> >> On 27 October 2015 at 16:24, Rafael J. Wysocki wrote:
> >> > Hi All,
> >> >
> >> > As discussed in the
On 28 October 2015 at 03:15, Rafael J. Wysocki wrote:
> On Tuesday, October 27, 2015 04:20:51 PM Tomeu Vizoso wrote:
>> On 27 October 2015 at 16:24, Rafael J. Wysocki wrote:
>> > Hi All,
>> >
>> > As discussed in the recent "On-demand device probing" thread and in a
>> > Kernel
>> > Summit
On Wednesday, October 28, 2015 03:26:14 PM Tomeu Vizoso wrote:
> On 28 October 2015 at 03:15, Rafael J. Wysocki wrote:
> > On Tuesday, October 27, 2015 04:20:51 PM Tomeu Vizoso wrote:
> >> On 27 October 2015 at 16:24, Rafael J. Wysocki wrote:
> >> > Hi
On 28 October 2015 at 03:15, Rafael J. Wysocki wrote:
> On Tuesday, October 27, 2015 04:20:51 PM Tomeu Vizoso wrote:
>> On 27 October 2015 at 16:24, Rafael J. Wysocki wrote:
>> > Hi All,
>> >
>> > As discussed in the recent "On-demand device probing"
On Tue, Oct 27, 2015 at 04:24:14PM +0100, Rafael J. Wysocki wrote:
> So, the question to everybody is whether or not this sounds reasonable or
> there
> are concerns about it and if so what they are. At this point I mostly need to
> know if I'm not overlooking anything fundamental at the
On Wed, Oct 28, 2015 at 04:54:04PM +0100, Rafael J. Wysocki wrote:
> Information that is already available at the device registration time should
> be used at that time or it makes things harder to follow.
> But that really is a tradeoff. If collecting that information requires too
> much
On Tuesday, October 27, 2015 04:20:51 PM Tomeu Vizoso wrote:
> On 27 October 2015 at 16:24, Rafael J. Wysocki wrote:
> > Hi All,
> >
> > As discussed in the recent "On-demand device probing" thread and in a Kernel
> > Summit session earlier today, there is a problem with handling cases where
> >
On 27 October 2015 at 16:24, Rafael J. Wysocki wrote:
> Hi All,
>
> As discussed in the recent "On-demand device probing" thread and in a Kernel
> Summit session earlier today, there is a problem with handling cases where
> functional dependencies between devices are involved.
>
> What I mean by
Hi All,
As discussed in the recent "On-demand device probing" thread and in a Kernel
Summit session earlier today, there is a problem with handling cases where
functional dependencies between devices are involved.
What I mean by a "functional dependency" is when the driver of device B needs
both
Hi All,
As discussed in the recent "On-demand device probing" thread and in a Kernel
Summit session earlier today, there is a problem with handling cases where
functional dependencies between devices are involved.
What I mean by a "functional dependency" is when the driver of device B needs
both
On 27 October 2015 at 16:24, Rafael J. Wysocki wrote:
> Hi All,
>
> As discussed in the recent "On-demand device probing" thread and in a Kernel
> Summit session earlier today, there is a problem with handling cases where
> functional dependencies between devices are involved.
On Tuesday, October 27, 2015 04:20:51 PM Tomeu Vizoso wrote:
> On 27 October 2015 at 16:24, Rafael J. Wysocki wrote:
> > Hi All,
> >
> > As discussed in the recent "On-demand device probing" thread and in a Kernel
> > Summit session earlier today, there is a problem with
70 matches
Mail list logo