Okay, thanks for the reviews. My hope was to avoid having to add that
feature into each driver, but that's okay.
-Charlie
On Fri, Mar 6, 2015 at 3:33 PM, Marcel Holtmann wrote:
> Hi Charles,
>
Specifically this was motivated by a situation where we have one
device with
Okay, thanks for the reviews. My hope was to avoid having to add that
feature into each driver, but that's okay.
-Charlie
On Fri, Mar 6, 2015 at 3:33 PM, Marcel Holtmann mar...@holtmann.org wrote:
Hi Charles,
Specifically this was motivated by a situation where we have one
device with a
Hi Charles,
>>> Specifically this was motivated by a situation where we have one
>>> device with a dual-sourced touchscreen. Both use the same driver but
>>> have different hardware & fw. Our FW updating software therefore,
>>> needs to be able to update with the
On Thu, Mar 5, 2015 at 5:27 PM, Ming Lei wrote:
> On Fri, Mar 6, 2015 at 6:36 AM, Dmitry Torokhov wrote:
>> On Thu, Mar 5, 2015 at 2:12 PM, Marcel Holtmann wrote:
>>> Hi Dmitry,
>>>
>> Specifically this was motivated by a situation where we have one
>> device with a dual-sourced
Hi Charles,
Specifically this was motivated by a situation where we have one
device with a dual-sourced touchscreen. Both use the same driver but
have different hardware fw. Our FW updating software therefore,
needs to be able to update with the correct FW and detect all this
at
runtime
On Thu, Mar 5, 2015 at 5:27 PM, Ming Lei ming@canonical.com wrote:
On Fri, Mar 6, 2015 at 6:36 AM, Dmitry Torokhov d...@chromium.org wrote:
On Thu, Mar 5, 2015 at 2:12 PM, Marcel Holtmann mar...@holtmann.org wrote:
Hi Dmitry,
Specifically this was motivated by a situation where we have
On Fri, Mar 6, 2015 at 6:36 AM, Dmitry Torokhov wrote:
> On Thu, Mar 5, 2015 at 2:12 PM, Marcel Holtmann wrote:
>> Hi Dmitry,
>>
> Specifically this was motivated by a situation where we have one
> device with a dual-sourced touchscreen. Both use the same driver but
>
On Thu, Mar 5, 2015 at 2:12 PM, Marcel Holtmann wrote:
> Hi Dmitry,
>
Specifically this was motivated by a situation where we have one
device with a dual-sourced touchscreen. Both use the same driver but
have different hardware & fw. Our FW updating software therefore,
Hi Dmitry,
>>> Specifically this was motivated by a situation where we have one
>>> device with a dual-sourced touchscreen. Both use the same driver but
>>> have different hardware & fw. Our FW updating software therefore,
>>> needs to be able to update with the correct FW and
Hi Dmitry,
> Specifically this was motivated by a situation where we have one
> device with a dual-sourced touchscreen. Both use the same driver but
> have different hardware & fw. Our FW updating software therefore,
> needs to be able to update with the correct FW and detect all
Hi Marcel,
On Thu, Mar 5, 2015 at 11:11 AM, Marcel Holtmann wrote:
> Hi Dmitry,
>
>> Specifically this was motivated by a situation where we have one
>> device with a dual-sourced touchscreen. Both use the same driver but
>> have different hardware & fw. Our FW updating software
On Thu, Mar 5, 2015 at 10:13 AM, Marcel Holtmann wrote:
> Hi Charles,
>
Specifically this was motivated by a situation where we have one
device with a dual-sourced touchscreen. Both use the same driver but
have different hardware & fw. Our FW updating software therefore,
needs
Hi Charles,
>>> Specifically this was motivated by a situation where we have one
>>> device with a dual-sourced touchscreen. Both use the same driver but
>>> have different hardware & fw. Our FW updating software therefore,
>>> needs to be able to update with the correct FW and detect all this at
On Thu, Mar 5, 2015 at 9:39 AM, Marcel Holtmann wrote:
> Hi Charles,
>
>> Specifically this was motivated by a situation where we have one
>> device with a dual-sourced touchscreen. Both use the same driver but
>> have different hardware & fw. Our FW updating software therefore,
>> needs to be
Hi Charles,
> Specifically this was motivated by a situation where we have one
> device with a dual-sourced touchscreen. Both use the same driver but
> have different hardware & fw. Our FW updating software therefore,
> needs to be able to update with the correct FW and detect all this at
>
Specifically this was motivated by a situation where we have one
device with a dual-sourced touchscreen. Both use the same driver but
have different hardware & fw. Our FW updating software therefore,
needs to be able to update with the correct FW and detect all this at
runtime due to a read-only
On Thu, Mar 5, 2015 at 8:48 AM, Dmitry Torokhov wrote:
> On Wed, Mar 04, 2015 at 03:57:09PM -0800, Greg KH wrote:
>> On Wed, Mar 04, 2015 at 03:25:10PM -0800, Charlie Mooney wrote:
>> > This patch adds an additional feature to the firmware_class.c module.
>> > To allow a unified method of
On Thu, Mar 5, 2015 at 2:12 PM, Marcel Holtmann mar...@holtmann.org wrote:
Hi Dmitry,
Specifically this was motivated by a situation where we have one
device with a dual-sourced touchscreen. Both use the same driver but
have different hardware fw. Our FW updating software therefore,
needs
Hi Dmitry,
Specifically this was motivated by a situation where we have one
device with a dual-sourced touchscreen. Both use the same driver but
have different hardware fw. Our FW updating software therefore,
needs to be able to update with the correct FW and detect all this at
runtime due
On Fri, Mar 6, 2015 at 6:36 AM, Dmitry Torokhov d...@chromium.org wrote:
On Thu, Mar 5, 2015 at 2:12 PM, Marcel Holtmann mar...@holtmann.org wrote:
Hi Dmitry,
Specifically this was motivated by a situation where we have one
device with a dual-sourced touchscreen. Both use the same driver but
Specifically this was motivated by a situation where we have one
device with a dual-sourced touchscreen. Both use the same driver but
have different hardware fw. Our FW updating software therefore,
needs to be able to update with the correct FW and detect all this at
runtime due to a read-only
Hi Charles,
Specifically this was motivated by a situation where we have one
device with a dual-sourced touchscreen. Both use the same driver but
have different hardware fw. Our FW updating software therefore,
needs to be able to update with the correct FW and detect all this at
runtime due
On Thu, Mar 5, 2015 at 9:39 AM, Marcel Holtmann mar...@holtmann.org wrote:
Hi Charles,
Specifically this was motivated by a situation where we have one
device with a dual-sourced touchscreen. Both use the same driver but
have different hardware fw. Our FW updating software therefore,
needs
On Thu, Mar 5, 2015 at 8:48 AM, Dmitry Torokhov d...@chromium.org wrote:
On Wed, Mar 04, 2015 at 03:57:09PM -0800, Greg KH wrote:
On Wed, Mar 04, 2015 at 03:25:10PM -0800, Charlie Mooney wrote:
This patch adds an additional feature to the firmware_class.c module.
To allow a unified method of
Hi Charles,
Specifically this was motivated by a situation where we have one
device with a dual-sourced touchscreen. Both use the same driver but
have different hardware fw. Our FW updating software therefore,
needs to be able to update with the correct FW and detect all this at
runtime due
On Thu, Mar 5, 2015 at 10:13 AM, Marcel Holtmann mar...@holtmann.org wrote:
Hi Charles,
Specifically this was motivated by a situation where we have one
device with a dual-sourced touchscreen. Both use the same driver but
have different hardware fw. Our FW updating software therefore,
needs
Hi Marcel,
On Thu, Mar 5, 2015 at 11:11 AM, Marcel Holtmann mar...@holtmann.org wrote:
Hi Dmitry,
Specifically this was motivated by a situation where we have one
device with a dual-sourced touchscreen. Both use the same driver but
have different hardware fw. Our FW updating software
Hi Dmitry,
Specifically this was motivated by a situation where we have one
device with a dual-sourced touchscreen. Both use the same driver but
have different hardware fw. Our FW updating software therefore,
needs to be able to update with the correct FW and detect all this at
runtime due
On Wed, Mar 04, 2015 at 03:57:09PM -0800, Greg KH wrote:
> On Wed, Mar 04, 2015 at 03:25:10PM -0800, Charlie Mooney wrote:
> > This patch adds an additional feature to the firmware_class.c module.
> > To allow a unified method of specifying new firmware locations when
> > drivers request a
On Wed, Mar 04, 2015 at 03:25:10PM -0800, Charlie Mooney wrote:
> This patch adds an additional feature to the firmware_class.c module.
> To allow a unified method of specifying new firmware locations when
> drivers request a firmware binary to update their devices with, we
> have added the
This patch adds an additional feature to the firmware_class.c module.
To allow a unified method of specifying new firmware locations when
drivers request a firmware binary to update their devices with, we
have added the concept of a "fw override"
A fw override is a rule that matches firmware
On Wed, Mar 04, 2015 at 03:57:09PM -0800, Greg KH wrote:
On Wed, Mar 04, 2015 at 03:25:10PM -0800, Charlie Mooney wrote:
This patch adds an additional feature to the firmware_class.c module.
To allow a unified method of specifying new firmware locations when
drivers request a firmware
This patch adds an additional feature to the firmware_class.c module.
To allow a unified method of specifying new firmware locations when
drivers request a firmware binary to update their devices with, we
have added the concept of a fw override
A fw override is a rule that matches firmware
On Wed, Mar 04, 2015 at 03:25:10PM -0800, Charlie Mooney wrote:
This patch adds an additional feature to the firmware_class.c module.
To allow a unified method of specifying new firmware locations when
drivers request a firmware binary to update their devices with, we
have added the concept of
34 matches
Mail list logo
