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

Groups > linux.kernel > #1253370 > unrolled thread

Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

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 v6 04/22] of: add function to allow probing a device from a OF node "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-22 02:40 +0200
    Re: [PATCH v6 04/22] of: add function to allow probing a device from  a OF node Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-22 15:10 +0200
      Re: [PATCH v6 04/22] of: add function to allow probing a device from  a OF node Mark Brown <broonie@kernel.org> - 2015-10-23 02:00 +0200
        Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-24 16:00 +0200
      Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-24 15:30 +0200
        Re: [PATCH v6 04/22] of: add function to allow probing a device from  a OF node Rob Herring <robh@kernel.org> - 2015-10-26 00:00 +0100
          Re: [PATCH v6 04/22] of: add function to allow probing a device from  a OF node Mark Brown <broonie@kernel.org> - 2015-10-26 01:20 +0100
            Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2015-10-26 01:20 +0100
            Re: [PATCH v6 04/22] of: add function to allow probing a device from  a OF node "Rafael J. Wysocki" <rafael@kernel.org> - 2015-10-26 03:50 +0100
              Re: [PATCH v6 04/22] of: add function to allow probing a device from  a OF node Mark Brown <broonie@kernel.org> - 2015-10-26 04:10 +0100

#1253370 — Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

On Monday, September 21, 2015 04:02:44 PM Tomeu Vizoso wrote:
> Walks the OF tree up and finds the closest ancestor that has a struct
> device associated with it, probing it if isn't bound to a driver yet.
> 
> The above should ensure that the dependency represented by the passed OF
> node is available, because probing a device should cause its descendants
> to be probed as well (when they get registered).
> 
> Subsystems can use this when looking up resources for drivers, to reduce
> the chances of deferred probes because of the probing order of devices.
> 
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> ---
> 
> Changes in v5:
> - Move the assignment to device_node->device for AMBA devices to another
>   commit.
> - Hold a reference to the struct device while it's in use in
>   of_device_probe().
> 
> Changes in v4:
> - Rename of_platform_probe to of_device_probe
> - Use device_node.device instead of device_node.platform_dev
> 
> Changes in v3:
> - Set and use device_node.platform_dev instead of reversing the logic to
>   find the platform device that encloses a device node.
> - Drop the fwnode API to probe firmware nodes and add OF-only API for
>   now. I think this same scheme could be used for machines with ACPI,
>   but I haven't been able to find one that had to defer its probes because
>   of the device probe order.
> 
>  drivers/of/device.c       | 61 +++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_device.h |  3 +++
>  2 files changed, 64 insertions(+)
> 
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index 8b91ea241b10..836be71fc90e 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -286,3 +286,64 @@ int of_device_uevent_modalias(struct device *dev, struct kobj_uevent_env *env)
>  
>  	return 0;
>  }
> +
> +/**
> + * of_device_probe() - Probe device associated with OF node
> + * @np: node to probe
> + *
> + * Probe the device associated with the passed device node.
> + */
> +void of_device_probe(struct device_node *np)

Same question as from Greg: How does a subsystem know whether or not to use
this function?

> +{
> +	struct device_node *target;
> +	struct device *dev = NULL;
> +
> +	if (!of_root || !of_node_check_flag(of_root, OF_POPULATED_BUS))
> +		return;
> +
> +	if (!np)
> +		return;
> +
> +	of_node_get(np);
> +
> +	/* Find the closest ancestor that has a device associated */
> +	for (target = np;
> +	     !of_node_is_root(target);
> +	     target = of_get_next_parent(target))
> +		if (get_device(target->device)) {
> +			dev = target->device;
> +			break;
> +		}
> +
> +	of_node_put(target);
> +
> +	if (!dev) {
> +		pr_warn("Couldn't find a device for node '%s'\n",
> +			of_node_full_name(np));
> +		return;
> +	}
> +
> +	/*
> +	 * Device is bound or is being probed right now. If we have bad luck
> +	 * and the dependency isn't ready when it's needed, deferred probe
> +	 * will save us.
> +	 */
> +	if (dev->driver)
> +		goto out;
> +
> +	/*
> +	 * Probing a device should cause its descendants to be probed as
> +	 * well, which includes the passed device node.
> +	 */
> +	if (device_attach(dev) != 1)
> +		/*
> +		 * This cannot be a warning for now because clock nodes have a
> +		 * compatible string but the clock framework doesn't follow
> +		 * the device/driver model yet.
> +		 */
> +		dev_dbg(dev, "Probe failed for %s\n", of_node_full_name(np));
> +
> +out:
> +	put_device(dev);
> +}
> +EXPORT_SYMBOL_GPL(of_device_probe);
> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
> index cc7dd687a89d..da8d489e73ad 100644
> --- a/include/linux/of_device.h
> +++ b/include/linux/of_device.h
> @@ -40,6 +40,7 @@ extern ssize_t of_device_get_modalias(struct device *dev,
>  
>  extern void of_device_uevent(struct device *dev, struct kobj_uevent_env *env);
>  extern int of_device_uevent_modalias(struct device *dev, struct kobj_uevent_env *env);
> +extern void of_device_probe(struct device_node *np);
>  
>  static inline void of_device_node_put(struct device *dev)
>  {
> @@ -84,6 +85,8 @@ static inline int of_device_uevent_modalias(struct device *dev,
>  	return -ENODEV;
>  }
>  
> +static inline void of_device_probe(struct device_node *np) { }
> +
>  static inline void of_device_node_put(struct device *dev) { }
>  
>  static inline const struct of_device_id *__of_match_device(
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] | [next] | [standalone]

#1253789 — Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

On 22 October 2015 at 03:06, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Monday, September 21, 2015 04:02:44 PM Tomeu Vizoso wrote:
>> Walks the OF tree up and finds the closest ancestor that has a struct
>> device associated with it, probing it if isn't bound to a driver yet.
>>
>> The above should ensure that the dependency represented by the passed OF
>> node is available, because probing a device should cause its descendants
>> to be probed as well (when they get registered).
>>
>> Subsystems can use this when looking up resources for drivers, to reduce
>> the chances of deferred probes because of the probing order of devices.
>>
>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>> ---
>>
>> Changes in v5:
>> - Move the assignment to device_node->device for AMBA devices to another
>>   commit.
>> - Hold a reference to the struct device while it's in use in
>>   of_device_probe().
>>
>> Changes in v4:
>> - Rename of_platform_probe to of_device_probe
>> - Use device_node.device instead of device_node.platform_dev
>>
>> Changes in v3:
>> - Set and use device_node.platform_dev instead of reversing the logic to
>>   find the platform device that encloses a device node.
>> - Drop the fwnode API to probe firmware nodes and add OF-only API for
>>   now. I think this same scheme could be used for machines with ACPI,
>>   but I haven't been able to find one that had to defer its probes because
>>   of the device probe order.
>>
>>  drivers/of/device.c       | 61 +++++++++++++++++++++++++++++++++++++++++++++++
>>  include/linux/of_device.h |  3 +++
>>  2 files changed, 64 insertions(+)
>>
>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>> index 8b91ea241b10..836be71fc90e 100644
>> --- a/drivers/of/device.c
>> +++ b/drivers/of/device.c
>> @@ -286,3 +286,64 @@ int of_device_uevent_modalias(struct device *dev, struct kobj_uevent_env *env)
>>
>>       return 0;
>>  }
>> +
>> +/**
>> + * of_device_probe() - Probe device associated with OF node
>> + * @np: node to probe
>> + *
>> + * Probe the device associated with the passed device node.
>> + */
>> +void of_device_probe(struct device_node *np)
>
> Same question as from Greg: How does a subsystem know whether or not to use
> this function?

Maybe I don't understand the comment, but as the commit message says,
subsystems can use this when looking up resources for drivers. Or you
mean that this information should be in the API docs?

Thanks,

Tomeu

>> +{
>> +     struct device_node *target;
>> +     struct device *dev = NULL;
>> +
>> +     if (!of_root || !of_node_check_flag(of_root, OF_POPULATED_BUS))
>> +             return;
>> +
>> +     if (!np)
>> +             return;
>> +
>> +     of_node_get(np);
>> +
>> +     /* Find the closest ancestor that has a device associated */
>> +     for (target = np;
>> +          !of_node_is_root(target);
>> +          target = of_get_next_parent(target))
>> +             if (get_device(target->device)) {
>> +                     dev = target->device;
>> +                     break;
>> +             }
>> +
>> +     of_node_put(target);
>> +
>> +     if (!dev) {
>> +             pr_warn("Couldn't find a device for node '%s'\n",
>> +                     of_node_full_name(np));
>> +             return;
>> +     }
>> +
>> +     /*
>> +      * Device is bound or is being probed right now. If we have bad luck
>> +      * and the dependency isn't ready when it's needed, deferred probe
>> +      * will save us.
>> +      */
>> +     if (dev->driver)
>> +             goto out;
>> +
>> +     /*
>> +      * Probing a device should cause its descendants to be probed as
>> +      * well, which includes the passed device node.
>> +      */
>> +     if (device_attach(dev) != 1)
>> +             /*
>> +              * This cannot be a warning for now because clock nodes have a
>> +              * compatible string but the clock framework doesn't follow
>> +              * the device/driver model yet.
>> +              */
>> +             dev_dbg(dev, "Probe failed for %s\n", of_node_full_name(np));
>> +
>> +out:
>> +     put_device(dev);
>> +}
>> +EXPORT_SYMBOL_GPL(of_device_probe);
>> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
>> index cc7dd687a89d..da8d489e73ad 100644
>> --- a/include/linux/of_device.h
>> +++ b/include/linux/of_device.h
>> @@ -40,6 +40,7 @@ extern ssize_t of_device_get_modalias(struct device *dev,
>>
>>  extern void of_device_uevent(struct device *dev, struct kobj_uevent_env *env);
>>  extern int of_device_uevent_modalias(struct device *dev, struct kobj_uevent_env *env);
>> +extern void of_device_probe(struct device_node *np);
>>
>>  static inline void of_device_node_put(struct device *dev)
>>  {
>> @@ -84,6 +85,8 @@ static inline int of_device_uevent_modalias(struct device *dev,
>>       return -ENODEV;
>>  }
>>
>> +static inline void of_device_probe(struct device_node *np) { }
>> +
>>  static inline void of_device_node_put(struct device *dev) { }
>>
>>  static inline const struct of_device_id *__of_match_device(
>>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
> --
> 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/
--
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]

#1254248 — Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

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

On Thu, Oct 22, 2015 at 03:03:37PM +0200, Tomeu Vizoso wrote:
> On 22 October 2015 at 03:06, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:

> > Same question as from Greg: How does a subsystem know whether or not to use
> > this function?

> Maybe I don't understand the comment, but as the commit message says,
> subsystems can use this when looking up resources for drivers. Or you
> mean that this information should be in the API docs?

I'm pretty sure what he's suggesting here is changing to "should always"
(ie, explain the situations when a subsystem would do this, including
decision criteria if it's optional).

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

#1255185

On Friday, October 23, 2015 08:54:19 AM Mark Brown wrote:
> 
> --7cm2iqirTL37Ot+N
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> On Thu, Oct 22, 2015 at 03:03:37PM +0200, Tomeu Vizoso wrote:
> > On 22 October 2015 at 03:06, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> 
> > > Same question as from Greg: How does a subsystem know whether or not to use
> > > this function?
> 
> > Maybe I don't understand the comment, but as the commit message says,
> > subsystems can use this when looking up resources for drivers. Or you
> > mean that this information should be in the API docs?
> 
> I'm pretty sure what he's suggesting here is changing to "should always"
> (ie, explain the situations when a subsystem would do this, including
> decision criteria if it's optional).

Right.

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]

#1255179

On Thursday, October 22, 2015 03:03:37 PM Tomeu Vizoso wrote:
> On 22 October 2015 at 03:06, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Monday, September 21, 2015 04:02:44 PM Tomeu Vizoso wrote:
> >> Walks the OF tree up and finds the closest ancestor that has a struct
> >> device associated with it, probing it if isn't bound to a driver yet.
> >>
> >> The above should ensure that the dependency represented by the passed OF
> >> node is available, because probing a device should cause its descendants
> >> to be probed as well (when they get registered).
> >>
> >> Subsystems can use this when looking up resources for drivers, to reduce
> >> the chances of deferred probes because of the probing order of devices.
> >>
> >> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> >> ---
> >>
> >> Changes in v5:
> >> - Move the assignment to device_node->device for AMBA devices to another
> >>   commit.
> >> - Hold a reference to the struct device while it's in use in
> >>   of_device_probe().
> >>
> >> Changes in v4:
> >> - Rename of_platform_probe to of_device_probe
> >> - Use device_node.device instead of device_node.platform_dev
> >>
> >> Changes in v3:
> >> - Set and use device_node.platform_dev instead of reversing the logic to
> >>   find the platform device that encloses a device node.
> >> - Drop the fwnode API to probe firmware nodes and add OF-only API for
> >>   now. I think this same scheme could be used for machines with ACPI,
> >>   but I haven't been able to find one that had to defer its probes because
> >>   of the device probe order.
> >>
> >>  drivers/of/device.c       | 61 +++++++++++++++++++++++++++++++++++++++++++++++
> >>  include/linux/of_device.h |  3 +++
> >>  2 files changed, 64 insertions(+)
> >>
> >> diff --git a/drivers/of/device.c b/drivers/of/device.c
> >> index 8b91ea241b10..836be71fc90e 100644
> >> --- a/drivers/of/device.c
> >> +++ b/drivers/of/device.c
> >> @@ -286,3 +286,64 @@ int of_device_uevent_modalias(struct device *dev, struct kobj_uevent_env *env)
> >>
> >>       return 0;
> >>  }
> >> +
> >> +/**
> >> + * of_device_probe() - Probe device associated with OF node
> >> + * @np: node to probe
> >> + *
> >> + * Probe the device associated with the passed device node.
> >> + */
> >> +void of_device_probe(struct device_node *np)
> >
> > Same question as from Greg: How does a subsystem know whether or not to use
> > this function?
> 
> Maybe I don't understand the comment, but as the commit message says,
> subsystems can use this when looking up resources for drivers. Or you
> mean that this information should be in the API docs?

I'm not really sure this is the only case.

Most likely, you'd end up with that being called by every subsystem using DT
just in case.

And then each of those subsystems would need to call acpi_device_probe(), and
then another_platform_firmware_interface_device_probe() and so on.

Don't you see a problem here?

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]

#1255582 — Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

On 10/24/2015 08:55 AM, Rafael J. Wysocki wrote:
> On Thursday, October 22, 2015 03:03:37 PM Tomeu Vizoso wrote:
>> On 22 October 2015 at 03:06, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>>> On Monday, September 21, 2015 04:02:44 PM Tomeu Vizoso wrote:
>>>> Walks the OF tree up and finds the closest ancestor that has a struct
>>>> device associated with it, probing it if isn't bound to a driver yet.
>>>>
>>>> The above should ensure that the dependency represented by the passed OF
>>>> node is available, because probing a device should cause its descendants
>>>> to be probed as well (when they get registered).
>>>>
>>>> Subsystems can use this when looking up resources for drivers, to reduce
>>>> the chances of deferred probes because of the probing order of devices.
>>>>
>>>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>>>> ---
>>>>
>>>> Changes in v5:
>>>> - Move the assignment to device_node->device for AMBA devices to another
>>>>   commit.
>>>> - Hold a reference to the struct device while it's in use in
>>>>   of_device_probe().
>>>>
>>>> Changes in v4:
>>>> - Rename of_platform_probe to of_device_probe
>>>> - Use device_node.device instead of device_node.platform_dev
>>>>
>>>> Changes in v3:
>>>> - Set and use device_node.platform_dev instead of reversing the logic to
>>>>   find the platform device that encloses a device node.
>>>> - Drop the fwnode API to probe firmware nodes and add OF-only API for
>>>>   now. I think this same scheme could be used for machines with ACPI,
>>>>   but I haven't been able to find one that had to defer its probes because
>>>>   of the device probe order.
>>>>
>>>>  drivers/of/device.c       | 61 +++++++++++++++++++++++++++++++++++++++++++++++
>>>>  include/linux/of_device.h |  3 +++
>>>>  2 files changed, 64 insertions(+)
>>>>
>>>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>>>> index 8b91ea241b10..836be71fc90e 100644
>>>> --- a/drivers/of/device.c
>>>> +++ b/drivers/of/device.c
>>>> @@ -286,3 +286,64 @@ int of_device_uevent_modalias(struct device *dev, struct kobj_uevent_env *env)
>>>>
>>>>       return 0;
>>>>  }
>>>> +
>>>> +/**
>>>> + * of_device_probe() - Probe device associated with OF node
>>>> + * @np: node to probe
>>>> + *
>>>> + * Probe the device associated with the passed device node.
>>>> + */
>>>> +void of_device_probe(struct device_node *np)
>>>
>>> Same question as from Greg: How does a subsystem know whether or not to use
>>> this function?
>>
>> Maybe I don't understand the comment, but as the commit message says,
>> subsystems can use this when looking up resources for drivers. Or you
>> mean that this information should be in the API docs?
> 
> I'm not really sure this is the only case.
> 
> Most likely, you'd end up with that being called by every subsystem using DT
> just in case.

No, it is binding dependent. If a consumer is looking up the provider
from the binding, then yes it needs a call. There may be some cases
where it doesn't make sense. But that is why it is called from the
binding specific code.

> And then each of those subsystems would need to call acpi_device_probe(), and
> then another_platform_firmware_interface_device_probe() and so on.
> 
> Don't you see a problem here?

Only for the 3rd firmware interface. ;)

Let's get agreement on the flow and structure and how to address other
issues like suspend, then we can worry about whether this needs to be
abstracted from subsystems. We can discuss more this week at KS.

Rob

--
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]

#1255589 — Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

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

On Sat, Oct 24, 2015 at 03:09:06PM -0500, Rob Herring wrote:

> Let's get agreement on the flow and structure and how to address other
> issues like suspend, then we can worry about whether this needs to be
> abstracted from subsystems. We can discuss more this week at KS.

Should we try to schedule an ad-hoc session today (Monday) for those of
us who are here to talk this over?

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

#1255591

On October 26, 2015 9:13:01 AM GMT+09:00, Mark Brown <broonie@kernel.org> wrote:
>On Sat, Oct 24, 2015 at 03:09:06PM -0500, Rob Herring wrote:
>
>> Let's get agreement on the flow and structure and how to address
>other
>> issues like suspend, then we can worry about whether this needs to be
>> abstracted from subsystems. We can discuss more this week at KS.
>
>Should we try to schedule an ad-hoc session today (Monday) for those of
>us who are here to talk this over?


That would be great.

Thanks.

-- 
Dmitry
--
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]

#1255627 — Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

On Mon, Oct 26, 2015 at 1:13 AM, Mark Brown <broonie@kernel.org> wrote:
> On Sat, Oct 24, 2015 at 03:09:06PM -0500, Rob Herring wrote:
>
>> Let's get agreement on the flow and structure and how to address other
>> issues like suspend, then we can worry about whether this needs to be
>> abstracted from subsystems. We can discuss more this week at KS.
>
> Should we try to schedule an ad-hoc session today (Monday) for those of
> us who are here to talk this over?

I won't mind doing that, what about after the Linus+Dirk session?

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]

#1255630 — Re: [PATCH v6 04/22] of: add function to allow probing a device from a OF node

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

On Mon, Oct 26, 2015 at 03:48:44AM +0100, Rafael J. Wysocki wrote:
> On Mon, Oct 26, 2015 at 1:13 AM, Mark Brown <broonie@kernel.org> wrote:

> > Should we try to schedule an ad-hoc session today (Monday) for those of
> > us who are here to talk this over?

> I won't mind doing that, what about after the Linus+Dirk session?

It's looking hard to round people up...  I asked Ted for a slot
tomorrow, hopefully we can get one and if not it's probably going to be
easier to find everyone at once.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web