Re: [PATCH] firmware_class: Add firmware filename overrides
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 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 partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. >>> >>> what is the actual problem here? We have drivers that load multiple >>> firmware files and we have drivers that pick a different firmware >>> depending on some parameters it reads from the device. >>> >>> Seems this is all possible already at the moment with the existing >>> framework. You just need to update the drivers to operate properly. >>> >> >> I totally agree, this functionality is not novel. We could have >> added >> this feature into the specific driver in question, but then we will >> have to do the same thing on all the other drivers we might want to >> do >> this on. I guess the real problem that this solves is by adding the >> change here, it allows you to override firmware names for *any* >> driver >> without having to duplicate the functionality in each one as they >> come >> up. >> >> For a specific instance, here at ChromiumOS we have devices that use >> Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that >> all can encounter this issue. The Atmel driver has a similar version >> of this feature baked into it but the others don't. We could add a >> fw_filename attribute to each of these drivers, but then it would >> have >> to be maintained across (at least) four drivers. > > what I am hearing here is that you can not query the hardware and > figure out which manufacturer it is and with that don't know which > firmware you need. Right, the drivers in question (bunch of input drivers such as elan_ts, atmel_mxt_ts, etc) might not be able to determine the "proper" configuration to load. Factories quite often swap pin-compatible parts and want to use the same image. Also the parts can be swapped out during RMA while keeping the same image. Userspace is able to query magnitude of sources and make an informed decision that it then communicates to the kernel. > However if that is the case, then this seems to be something that > should be solved with device tree. Why are we making device tree a hard dependency here? >>> >>> device tree is suppose to describe the hardware in your devices. If you >>> can not determinate your hardware by enumeration or other means, then >>> it should be done via device tree. Seems the perfect fit here. >> >> And if I do not have device tree? > > so if you do not have an enumeration method for your hardware, then I > assume you most likely have device tree in one form or another. > > And even if you really don't, nothing is stopping you from adding device > tree. We have ACPI (for example) and no, it is not 5.0. >>> >>> It depends if the driver can determinate what the device is from >>> ACPI. If yes, you can just load the corresponding fw image >>> for the current device. Otherwise the ACPI can't help your problem. >> >> We run into the situation where to very similar devices (all the same >> HW models) need to ship with the same OS image. One
Re: [PATCH] firmware_class: Add firmware filename overrides
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 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 partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. Right, the drivers in question (bunch of input drivers such as elan_ts, atmel_mxt_ts, etc) might not be able to determine the proper configuration to load. Factories quite often swap pin-compatible parts and want to use the same image. Also the parts can be swapped out during RMA while keeping the same image. Userspace is able to query magnitude of sources and make an informed decision that it then communicates to the kernel. However if that is the case, then this seems to be something that should be solved with device tree. Why are we making device tree a hard dependency here? device tree is suppose to describe the hardware in your devices. If you can not determinate your hardware by enumeration or other means, then it should be done via device tree. Seems the perfect fit here. And if I do not have device tree? so if you do not have an enumeration method for your hardware, then I assume you most likely have device tree in one form or another. And even if you really don't, nothing is stopping you from adding device tree. We have ACPI (for example) and no, it is not 5.0. It depends if the driver can determinate what the device is from ACPI. If yes, you can just load the corresponding fw image for the current device. Otherwise the ACPI can't help your problem. We run into the situation where to very similar devices (all the same HW models) need to ship with the same OS image. One device may have a pin-for-pin compatable, 2nd source version of some piece of hardware. The device tree/etc is all the same because the two slighty different parts are connected the same way (same i2c address, or similar). The only way to tell them apart is by talking to the driver once the device is already up and running. In our motivating case it's reading a sysfs attribute to get a manufacturer ID, but it could be anything similar. If you want to be able to put a different FW on these two very similar devices (that can only be differentiated once they're up and running) I think this might be the best way to do it -- apart from altering the driver for every part that needs this kind of special treatment. if you can get a manufacturer ID over sysfs, then you can obviously pick the right firmware from within the driver. No need to
Re: [PATCH] firmware_class: Add firmware filename overrides
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 to a read-only partition (so moving the firmware >>> binaries >>> around isn't really an option) >>> Here the device has only one touchscreen at a time, but it isn't >>> known >>> until run-time which will be present. >>> >>> So in this case the driver is serving the same function in each >>> situation (running a touchscreen) but may be working with different >>> hardware. >>> >>> Another situation where I've personally wanted this functionality is >>> on a device that uses the same touch driver for both a touchscreen >>> and >>> a touchpad on the same device. If the driver only grabs a copy of FW >>> from, say, /lib/firmware/touch_fw.bin then you either need to move >>> the >>> firmware binaries around on disk to update either device, or have a >>> change like this that allows you to override which filename it >>> loads. >>> The moving option is not viable if you're using a RO filesystem. >> >> what is the actual problem here? We have drivers that load multiple >> firmware files and we have drivers that pick a different firmware >> depending on some parameters it reads from the device. >> >> Seems this is all possible already at the moment with the existing >> framework. You just need to update the drivers to operate properly. >> > > I totally agree, this functionality is not novel. We could have added > this feature into the specific driver in question, but then we will > have to do the same thing on all the other drivers we might want to do > this on. I guess the real problem that this solves is by adding the > change here, it allows you to override firmware names for *any* driver > without having to duplicate the functionality in each one as they come > up. > > For a specific instance, here at ChromiumOS we have devices that use > Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that > all can encounter this issue. The Atmel driver has a similar version > of this feature baked into it but the others don't. We could add a > fw_filename attribute to each of these drivers, but then it would have > to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. >>> >>> Right, the drivers in question (bunch of input drivers such as >>> elan_ts, atmel_mxt_ts, etc) might not be able to determine the >>> "proper" configuration to load. Factories quite often swap >>> pin-compatible parts and want to use the same image. Also the parts >>> can be swapped out during RMA while keeping the same image. Userspace >>> is able to query magnitude of sources and make an informed decision >>> that it then communicates to the kernel. >>> However if that is the case, then this seems to be something that should be solved with device tree. >>> >>> Why are we making device tree a hard dependency here? >> >> device tree is suppose to describe the hardware in your devices. If you >> can not determinate your hardware by enumeration or other means, then it >> should be done via device tree. Seems the perfect fit here. > > And if I do not have device tree? so if you do not have an enumeration method for your hardware, then I assume you most likely have device tree in one form or another. And even if you really don't, nothing is stopping you from adding device tree. >>> >>> We have ACPI (for example) and no, it is not 5.0. >> >> It depends if the driver can determinate what the device is from >> ACPI. If yes, you can just load the corresponding fw image >> for the current device. Otherwise the ACPI can't help your problem. > > We run into the situation where to very similar devices (all the same > HW models) need to ship with the same OS image. One device may have a > pin-for-pin compatable, 2nd source version of some piece of hardware. > The device tree/etc is all the same because the two slighty different > parts are connected the same way (same i2c address, or similar). > > The only way to tell them apart is by talking to the driver once the > device is already up and running. In our motivating
Re: [PATCH] firmware_class: Add firmware filename overrides
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 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 partition (so moving the firmware binaries >> around isn't really an option) >> Here the device has only one touchscreen at a time, but it isn't >> known >> until run-time which will be present. >> >> So in this case the driver is serving the same function in each >> situation (running a touchscreen) but may be working with different >> hardware. >> >> Another situation where I've personally wanted this functionality is >> on a device that uses the same touch driver for both a touchscreen >> and >> a touchpad on the same device. If the driver only grabs a copy of FW >> from, say, /lib/firmware/touch_fw.bin then you either need to move >> the >> firmware binaries around on disk to update either device, or have a >> change like this that allows you to override which filename it loads. >> The moving option is not viable if you're using a RO filesystem. > > what is the actual problem here? We have drivers that load multiple > firmware files and we have drivers that pick a different firmware > depending on some parameters it reads from the device. > > Seems this is all possible already at the moment with the existing > framework. You just need to update the drivers to operate properly. > I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. >>> >>> what I am hearing here is that you can not query the hardware and >>> figure out which manufacturer it is and with that don't know which >>> firmware you need. >> >> Right, the drivers in question (bunch of input drivers such as >> elan_ts, atmel_mxt_ts, etc) might not be able to determine the >> "proper" configuration to load. Factories quite often swap >> pin-compatible parts and want to use the same image. Also the parts >> can be swapped out during RMA while keeping the same image. Userspace >> is able to query magnitude of sources and make an informed decision >> that it then communicates to the kernel. >> >>> However if that is the case, then this seems to be something that >>> should be solved with device tree. >> >> Why are we making device tree a hard dependency here? > > device tree is suppose to describe the hardware in your devices. If you > can not determinate your hardware by enumeration or other means, then it > should be done via device tree. Seems the perfect fit here. And if I do not have device tree? >>> >>> so if you do not have an enumeration method for your hardware, then I >>> assume you most likely have device tree in one form or another. >>> >>> And even if you really don't, nothing is stopping you from adding device >>> tree. >> >> We have ACPI (for example) and no, it is not 5.0. > > It depends if the driver can determinate what the device is from > ACPI. If yes, you can just load the corresponding fw image > for the current device. Otherwise the ACPI can't help your problem. > > Thanks, > Ming Lei We run into the situation where to very similar devices (all the same HW models) need to ship with the same OS image. One device may have a pin-for-pin compatable, 2nd source version of some piece of hardware. The device tree/etc is all the same because the two slighty different parts are connected the same way (same i2c address, or similar). The only way to tell them apart is by talking to the driver once the device is
Re: [PATCH] firmware_class: Add firmware filename overrides
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 to a read-only partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. Right, the drivers in question (bunch of input drivers such as elan_ts, atmel_mxt_ts, etc) might not be able to determine the proper configuration to load. Factories quite often swap pin-compatible parts and want to use the same image. Also the parts can be swapped out during RMA while keeping the same image. Userspace is able to query magnitude of sources and make an informed decision that it then communicates to the kernel. However if that is the case, then this seems to be something that should be solved with device tree. Why are we making device tree a hard dependency here? device tree is suppose to describe the hardware in your devices. If you can not determinate your hardware by enumeration or other means, then it should be done via device tree. Seems the perfect fit here. And if I do not have device tree? so if you do not have an enumeration method for your hardware, then I assume you most likely have device tree in one form or another. And even if you really don't, nothing is stopping you from adding device tree. We have ACPI (for example) and no, it is not 5.0. It depends if the driver can determinate what the device is from ACPI. If yes, you can just load the corresponding fw image for the current device. Otherwise the ACPI can't help your problem. We run into the situation where to very similar devices (all the same HW models) need to ship with the same OS image. One device may have a pin-for-pin compatable, 2nd source version of some piece of hardware. The device tree/etc is all the same because the two slighty different parts are connected the same way (same i2c address, or similar). The only way to tell them apart is by talking to the driver once the device is already up and running. In our motivating case it's reading a sysfs attribute to get a manufacturer ID, but it could be anything similar. If you want to be able to put a different FW on these two very similar devices (that can only be differentiated once they're up and running) I think this might be the best way to do it -- apart from altering the driver for every part that needs this kind of special treatment. if you can get a manufacturer ID over sysfs, then you can obviously pick the right firmware from within the driver. No need to play any tricks in userspace or the request_firmware interface. Regards Marcel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to
Re: [PATCH] firmware_class: Add firmware filename overrides
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 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 partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. Right, the drivers in question (bunch of input drivers such as elan_ts, atmel_mxt_ts, etc) might not be able to determine the proper configuration to load. Factories quite often swap pin-compatible parts and want to use the same image. Also the parts can be swapped out during RMA while keeping the same image. Userspace is able to query magnitude of sources and make an informed decision that it then communicates to the kernel. However if that is the case, then this seems to be something that should be solved with device tree. Why are we making device tree a hard dependency here? device tree is suppose to describe the hardware in your devices. If you can not determinate your hardware by enumeration or other means, then it should be done via device tree. Seems the perfect fit here. And if I do not have device tree? so if you do not have an enumeration method for your hardware, then I assume you most likely have device tree in one form or another. And even if you really don't, nothing is stopping you from adding device tree. We have ACPI (for example) and no, it is not 5.0. It depends if the driver can determinate what the device is from ACPI. If yes, you can just load the corresponding fw image for the current device. Otherwise the ACPI can't help your problem. Thanks, Ming Lei We run into the situation where to very similar devices (all the same HW models) need to ship with the same OS image. One device may have a pin-for-pin compatable, 2nd source version of some piece of hardware. The device tree/etc is all the same because the two slighty different parts are connected the same way (same i2c address, or similar). The only way to tell them apart is by talking to the driver once the device is already up and running. In our motivating case it's reading a sysfs attribute to get a manufacturer ID, but it could be anything similar. If you want to be able to put a different FW on these two very similar devices (that can only be differentiated once they're up and running) I think this might be the best way to do it -- apart from altering the driver for every part that needs this kind of special treatment. -Charlie -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to
Re: [PATCH] firmware_class: Add firmware filename overrides
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 > 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 partition (so moving the firmware binaries > around isn't really an option) > Here the device has only one touchscreen at a time, but it isn't known > until run-time which will be present. > > So in this case the driver is serving the same function in each > situation (running a touchscreen) but may be working with different > hardware. > > Another situation where I've personally wanted this functionality is > on a device that uses the same touch driver for both a touchscreen and > a touchpad on the same device. If the driver only grabs a copy of FW > from, say, /lib/firmware/touch_fw.bin then you either need to move the > firmware binaries around on disk to update either device, or have a > change like this that allows you to override which filename it loads. > The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. >>> >>> I totally agree, this functionality is not novel. We could have added >>> this feature into the specific driver in question, but then we will >>> have to do the same thing on all the other drivers we might want to do >>> this on. I guess the real problem that this solves is by adding the >>> change here, it allows you to override firmware names for *any* driver >>> without having to duplicate the functionality in each one as they come >>> up. >>> >>> For a specific instance, here at ChromiumOS we have devices that use >>> Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that >>> all can encounter this issue. The Atmel driver has a similar version >>> of this feature baked into it but the others don't. We could add a >>> fw_filename attribute to each of these drivers, but then it would have >>> to be maintained across (at least) four drivers. >> >> what I am hearing here is that you can not query the hardware and figure >> out which manufacturer it is and with that don't know which firmware you >> need. > > Right, the drivers in question (bunch of input drivers such as > elan_ts, atmel_mxt_ts, etc) might not be able to determine the > "proper" configuration to load. Factories quite often swap > pin-compatible parts and want to use the same image. Also the parts > can be swapped out during RMA while keeping the same image. Userspace > is able to query magnitude of sources and make an informed decision > that it then communicates to the kernel. > >> However if that is the case, then this seems to be something that should >> be solved with device tree. > > Why are we making device tree a hard dependency here? device tree is suppose to describe the hardware in your devices. If you can not determinate your hardware by enumeration or other means, then it should be done via device tree. Seems the perfect fit here. >>> >>> And if I do not have device tree? >> >> so if you do not have an enumeration method for your hardware, then I assume >> you most likely have device tree in one form or another. >> >> And even if you really don't, nothing is stopping you from adding device >> tree. > > We have ACPI (for example) and no, it is not 5.0. It depends if the driver can determinate what the device is from ACPI. If yes, you can just load the corresponding fw image for the current device. Otherwise the ACPI can't help your problem. Thanks, Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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, needs to be able to update with the correct FW and detect all this at runtime due to a read-only partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. >>> >>> what is the actual problem here? We have drivers that load multiple >>> firmware files and we have drivers that pick a different firmware >>> depending on some parameters it reads from the device. >>> >>> Seems this is all possible already at the moment with the existing >>> framework. You just need to update the drivers to operate properly. >>> >> >> I totally agree, this functionality is not novel. We could have added >> this feature into the specific driver in question, but then we will >> have to do the same thing on all the other drivers we might want to do >> this on. I guess the real problem that this solves is by adding the >> change here, it allows you to override firmware names for *any* driver >> without having to duplicate the functionality in each one as they come >> up. >> >> For a specific instance, here at ChromiumOS we have devices that use >> Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that >> all can encounter this issue. The Atmel driver has a similar version >> of this feature baked into it but the others don't. We could add a >> fw_filename attribute to each of these drivers, but then it would have >> to be maintained across (at least) four drivers. > > what I am hearing here is that you can not query the hardware and figure > out which manufacturer it is and with that don't know which firmware you > need. Right, the drivers in question (bunch of input drivers such as elan_ts, atmel_mxt_ts, etc) might not be able to determine the "proper" configuration to load. Factories quite often swap pin-compatible parts and want to use the same image. Also the parts can be swapped out during RMA while keeping the same image. Userspace is able to query magnitude of sources and make an informed decision that it then communicates to the kernel. > However if that is the case, then this seems to be something that should > be solved with device tree. Why are we making device tree a hard dependency here? >>> >>> device tree is suppose to describe the hardware in your devices. If you can >>> not determinate your hardware by enumeration or other means, then it should >>> be done via device tree. Seems the perfect fit here. >> >> And if I do not have device tree? > > so if you do not have an enumeration method for your hardware, then I assume > you most likely have device tree in one form or another. > > And even if you really don't, nothing is stopping you from adding device tree. We have ACPI (for example) and no, it is not 5.0. Thanks, Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 to a read-only partition (so moving the firmware binaries >>> around isn't really an option) >>> Here the device has only one touchscreen at a time, but it isn't known >>> until run-time which will be present. >>> >>> So in this case the driver is serving the same function in each >>> situation (running a touchscreen) but may be working with different >>> hardware. >>> >>> Another situation where I've personally wanted this functionality is >>> on a device that uses the same touch driver for both a touchscreen and >>> a touchpad on the same device. If the driver only grabs a copy of FW >>> from, say, /lib/firmware/touch_fw.bin then you either need to move the >>> firmware binaries around on disk to update either device, or have a >>> change like this that allows you to override which filename it loads. >>> The moving option is not viable if you're using a RO filesystem. >> >> what is the actual problem here? We have drivers that load multiple >> firmware files and we have drivers that pick a different firmware >> depending on some parameters it reads from the device. >> >> Seems this is all possible already at the moment with the existing >> framework. You just need to update the drivers to operate properly. >> > > I totally agree, this functionality is not novel. We could have added > this feature into the specific driver in question, but then we will > have to do the same thing on all the other drivers we might want to do > this on. I guess the real problem that this solves is by adding the > change here, it allows you to override firmware names for *any* driver > without having to duplicate the functionality in each one as they come > up. > > For a specific instance, here at ChromiumOS we have devices that use > Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that > all can encounter this issue. The Atmel driver has a similar version > of this feature baked into it but the others don't. We could add a > fw_filename attribute to each of these drivers, but then it would have > to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. >>> >>> Right, the drivers in question (bunch of input drivers such as >>> elan_ts, atmel_mxt_ts, etc) might not be able to determine the >>> "proper" configuration to load. Factories quite often swap >>> pin-compatible parts and want to use the same image. Also the parts >>> can be swapped out during RMA while keeping the same image. Userspace >>> is able to query magnitude of sources and make an informed decision >>> that it then communicates to the kernel. >>> However if that is the case, then this seems to be something that should be solved with device tree. >>> >>> Why are we making device tree a hard dependency here? >> >> device tree is suppose to describe the hardware in your devices. If you can >> not determinate your hardware by enumeration or other means, then it should >> be done via device tree. Seems the perfect fit here. > > And if I do not have device tree? so if you do not have an enumeration method for your hardware, then I assume you most likely have device tree in one form or another. And even if you really don't, nothing is stopping you from adding device tree. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 to a read-only partition (so moving the firmware binaries > around isn't really an option) > Here the device has only one touchscreen at a time, but it isn't known > until run-time which will be present. > > So in this case the driver is serving the same function in each > situation (running a touchscreen) but may be working with different > hardware. > > Another situation where I've personally wanted this functionality is > on a device that uses the same touch driver for both a touchscreen and > a touchpad on the same device. If the driver only grabs a copy of FW > from, say, /lib/firmware/touch_fw.bin then you either need to move the > firmware binaries around on disk to update either device, or have a > change like this that allows you to override which filename it loads. > The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. >>> >>> I totally agree, this functionality is not novel. We could have added >>> this feature into the specific driver in question, but then we will >>> have to do the same thing on all the other drivers we might want to do >>> this on. I guess the real problem that this solves is by adding the >>> change here, it allows you to override firmware names for *any* driver >>> without having to duplicate the functionality in each one as they come >>> up. >>> >>> For a specific instance, here at ChromiumOS we have devices that use >>> Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that >>> all can encounter this issue. The Atmel driver has a similar version >>> of this feature baked into it but the others don't. We could add a >>> fw_filename attribute to each of these drivers, but then it would have >>> to be maintained across (at least) four drivers. >> >> what I am hearing here is that you can not query the hardware and figure out >> which manufacturer it is and with that don't know which firmware you need. > > Right, the drivers in question (bunch of input drivers such as > elan_ts, atmel_mxt_ts, etc) might not be able to determine the > "proper" configuration to load. Factories quite often swap > pin-compatible parts and want to use the same image. Also the parts > can be swapped out during RMA while keeping the same image. Userspace > is able to query magnitude of sources and make an informed decision > that it then communicates to the kernel. > >> However if that is the case, then this seems to be something that should be >> solved with device tree. > > Why are we making device tree a hard dependency here? device tree is suppose to describe the hardware in your devices. If you can not determinate your hardware by enumeration or other means, then it should be done via device tree. Seems the perfect fit here. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 therefore, >> needs to be able to update with the correct FW and detect all this at >> runtime due to a read-only partition (so moving the firmware binaries >> around isn't really an option) >> Here the device has only one touchscreen at a time, but it isn't known >> until run-time which will be present. >> >> So in this case the driver is serving the same function in each >> situation (running a touchscreen) but may be working with different >> hardware. >> >> Another situation where I've personally wanted this functionality is >> on a device that uses the same touch driver for both a touchscreen and >> a touchpad on the same device. If the driver only grabs a copy of FW >> from, say, /lib/firmware/touch_fw.bin then you either need to move the >> firmware binaries around on disk to update either device, or have a >> change like this that allows you to override which filename it loads. >> The moving option is not viable if you're using a RO filesystem. > > what is the actual problem here? We have drivers that load multiple > firmware files and we have drivers that pick a different firmware > depending on some parameters it reads from the device. > > Seems this is all possible already at the moment with the existing > framework. You just need to update the drivers to operate properly. > I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. >>> >>> what I am hearing here is that you can not query the hardware and figure >>> out which manufacturer it is and with that don't know which firmware you >>> need. >> >> Right, the drivers in question (bunch of input drivers such as >> elan_ts, atmel_mxt_ts, etc) might not be able to determine the >> "proper" configuration to load. Factories quite often swap >> pin-compatible parts and want to use the same image. Also the parts >> can be swapped out during RMA while keeping the same image. Userspace >> is able to query magnitude of sources and make an informed decision >> that it then communicates to the kernel. >> >>> However if that is the case, then this seems to be something that should be >>> solved with device tree. >> >> Why are we making device tree a hard dependency here? > > device tree is suppose to describe the hardware in your devices. If you can > not determinate your hardware by enumeration or other means, then it should > be done via device tree. Seems the perfect fit here. And if I do not have device tree? Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 to be able to update with the correct FW and detect all this at runtime due to a read-only partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. >>> >>> what is the actual problem here? We have drivers that load multiple >>> firmware files and we have drivers that pick a different firmware depending >>> on some parameters it reads from the device. >>> >>> Seems this is all possible already at the moment with the existing >>> framework. You just need to update the drivers to operate properly. >>> >> >> I totally agree, this functionality is not novel. We could have added >> this feature into the specific driver in question, but then we will >> have to do the same thing on all the other drivers we might want to do >> this on. I guess the real problem that this solves is by adding the >> change here, it allows you to override firmware names for *any* driver >> without having to duplicate the functionality in each one as they come >> up. >> >> For a specific instance, here at ChromiumOS we have devices that use >> Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that >> all can encounter this issue. The Atmel driver has a similar version >> of this feature baked into it but the others don't. We could add a >> fw_filename attribute to each of these drivers, but then it would have >> to be maintained across (at least) four drivers. > > what I am hearing here is that you can not query the hardware and figure out > which manufacturer it is and with that don't know which firmware you need. Right, the drivers in question (bunch of input drivers such as elan_ts, atmel_mxt_ts, etc) might not be able to determine the "proper" configuration to load. Factories quite often swap pin-compatible parts and want to use the same image. Also the parts can be swapped out during RMA while keeping the same image. Userspace is able to query magnitude of sources and make an informed decision that it then communicates to the kernel. > However if that is the case, then this seems to be something that should be > solved with device tree. Why are we making device tree a hard dependency here? Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 to a read-only partition (so moving the firmware binaries >>> around isn't really an option) >>> Here the device has only one touchscreen at a time, but it isn't known >>> until run-time which will be present. >>> >>> So in this case the driver is serving the same function in each >>> situation (running a touchscreen) but may be working with different >>> hardware. >>> >>> Another situation where I've personally wanted this functionality is >>> on a device that uses the same touch driver for both a touchscreen and >>> a touchpad on the same device. If the driver only grabs a copy of FW >>> from, say, /lib/firmware/touch_fw.bin then you either need to move the >>> firmware binaries around on disk to update either device, or have a >>> change like this that allows you to override which filename it loads. >>> The moving option is not viable if you're using a RO filesystem. >> >> what is the actual problem here? We have drivers that load multiple firmware >> files and we have drivers that pick a different firmware depending on some >> parameters it reads from the device. >> >> Seems this is all possible already at the moment with the existing >> framework. You just need to update the drivers to operate properly. >> > > I totally agree, this functionality is not novel. We could have added > this feature into the specific driver in question, but then we will > have to do the same thing on all the other drivers we might want to do > this on. I guess the real problem that this solves is by adding the > change here, it allows you to override firmware names for *any* driver > without having to duplicate the functionality in each one as they come > up. > > For a specific instance, here at ChromiumOS we have devices that use > Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that > all can encounter this issue. The Atmel driver has a similar version > of this feature baked into it but the others don't. We could add a > fw_filename attribute to each of these drivers, but then it would have > to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. However if that is the case, then this seems to be something that should be solved with device tree. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 able to update with the correct FW and detect all this at >> runtime due to a read-only partition (so moving the firmware binaries >> around isn't really an option) >> Here the device has only one touchscreen at a time, but it isn't known >> until run-time which will be present. >> >> So in this case the driver is serving the same function in each >> situation (running a touchscreen) but may be working with different >> hardware. >> >> Another situation where I've personally wanted this functionality is >> on a device that uses the same touch driver for both a touchscreen and >> a touchpad on the same device. If the driver only grabs a copy of FW >> from, say, /lib/firmware/touch_fw.bin then you either need to move the >> firmware binaries around on disk to update either device, or have a >> change like this that allows you to override which filename it loads. >> The moving option is not viable if you're using a RO filesystem. > > what is the actual problem here? We have drivers that load multiple firmware > files and we have drivers that pick a different firmware depending on some > parameters it reads from the device. > > Seems this is all possible already at the moment with the existing framework. > You just need to update the drivers to operate properly. > > Regards > > Marcel > I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 to a read-only partition (so moving the firmware binaries > around isn't really an option) > Here the device has only one touchscreen at a time, but it isn't known > until run-time which will be present. > > So in this case the driver is serving the same function in each > situation (running a touchscreen) but may be working with different > hardware. > > Another situation where I've personally wanted this functionality is > on a device that uses the same touch driver for both a touchscreen and > a touchpad on the same device. If the driver only grabs a copy of FW > from, say, /lib/firmware/touch_fw.bin then you either need to move the > firmware binaries around on disk to update either device, or have a > change like this that allows you to override which filename it loads. > The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. -Charlie On Thu, Mar 5, 2015 at 12:14 AM Ming Lei wrote: 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 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 requests based on the >> > name of the device requesting the fw and what the filename for the >> > fw they are requesting is, and overrides their requests with a new >> > value. >> > >> > Overrides are set up by piping a description of the override into >> > an attribute set up at /sys/class/firmware/fw_override. The string >> > should be a null-deliminited list of the firmware name you want to >> > over ride, the new name to replace it with, and the device name that >> > you want the override to apply to. For example you could set up >> > an override for a device called "my_device" so that any time it >> > requests a firmware called "my_fw.bin" it instead gets "new_fw.bin" >> > with the following command: >> > >> > echo -e 'my_fw.bin\0new_fw.bin\0my_device\0' > >> > /sys/class/firmware/fw_override >> >> I hate to ask, but I have to, why do you need this? > > We may have single driver serve several devices (a touchscreen and a > touchpad) that require different firmware/config file to function. We have I remember some wifi drivers have similar usage too: one driver serves several functions, and each function need its own firmware. So looks it is fine to use different firmware name for each different function, or my understanding about the use case is wrong? Thanks, Ming Lei > several options: > > - modify the driver to allow changing firmware name from userspace - gets > old when there are several drivers that need that; > - encode part numbers in the driver and request different firmware - not > easily maintainable, still has an issue that same part might be used for > different devices; > - replace the firmware file on disk before initiating firmware load - does > not work well with read-only file systems; > - have udev supply different data - udev went out of fashion; > - have one central place (firmware loader) that users can control to > override the names - this solution. > > Thanks. > > -- > Dmitry > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 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 requests based on the >> > name of the device requesting the fw and what the filename for the >> > fw they are requesting is, and overrides their requests with a new >> > value. >> > >> > Overrides are set up by piping a description of the override into >> > an attribute set up at /sys/class/firmware/fw_override. The string >> > should be a null-deliminited list of the firmware name you want to >> > over ride, the new name to replace it with, and the device name that >> > you want the override to apply to. For example you could set up >> > an override for a device called "my_device" so that any time it >> > requests a firmware called "my_fw.bin" it instead gets "new_fw.bin" >> > with the following command: >> > >> > echo -e 'my_fw.bin\0new_fw.bin\0my_device\0' > >> > /sys/class/firmware/fw_override >> >> I hate to ask, but I have to, why do you need this? > > We may have single driver serve several devices (a touchscreen and a > touchpad) that require different firmware/config file to function. We have I remember some wifi drivers have similar usage too: one driver serves several functions, and each function need its own firmware. So looks it is fine to use different firmware name for each different function, or my understanding about the use case is wrong? Thanks, Ming Lei > several options: > > - modify the driver to allow changing firmware name from userspace - gets > old when there are several drivers that need that; > - encode part numbers in the driver and request different firmware - not > easily maintainable, still has an issue that same part might be used for > different devices; > - replace the firmware file on disk before initiating firmware load - does > not work well with read-only file systems; > - have udev supply different data - udev went out of fashion; > - have one central place (firmware loader) that users can control to > override the names - this solution. > > Thanks. > > -- > Dmitry > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 to be able to update with the correct FW and detect all this at runtime due to a read-only partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. Right, the drivers in question (bunch of input drivers such as elan_ts, atmel_mxt_ts, etc) might not be able to determine the proper configuration to load. Factories quite often swap pin-compatible parts and want to use the same image. Also the parts can be swapped out during RMA while keeping the same image. Userspace is able to query magnitude of sources and make an informed decision that it then communicates to the kernel. However if that is the case, then this seems to be something that should be solved with device tree. Why are we making device tree a hard dependency here? device tree is suppose to describe the hardware in your devices. If you can not determinate your hardware by enumeration or other means, then it should be done via device tree. Seems the perfect fit here. And if I do not have device tree? so if you do not have an enumeration method for your hardware, then I assume you most likely have device tree in one form or another. And even if you really don't, nothing is stopping you from adding device tree. We have ACPI (for example) and no, it is not 5.0. Thanks, Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 to a read-only partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. Right, the drivers in question (bunch of input drivers such as elan_ts, atmel_mxt_ts, etc) might not be able to determine the proper configuration to load. Factories quite often swap pin-compatible parts and want to use the same image. Also the parts can be swapped out during RMA while keeping the same image. Userspace is able to query magnitude of sources and make an informed decision that it then communicates to the kernel. However if that is the case, then this seems to be something that should be solved with device tree. Why are we making device tree a hard dependency here? device tree is suppose to describe the hardware in your devices. If you can not determinate your hardware by enumeration or other means, then it should be done via device tree. Seems the perfect fit here. And if I do not have device tree? so if you do not have an enumeration method for your hardware, then I assume you most likely have device tree in one form or another. And even if you really don't, nothing is stopping you from adding device tree. Regards Marcel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 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 partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. Right, the drivers in question (bunch of input drivers such as elan_ts, atmel_mxt_ts, etc) might not be able to determine the proper configuration to load. Factories quite often swap pin-compatible parts and want to use the same image. Also the parts can be swapped out during RMA while keeping the same image. Userspace is able to query magnitude of sources and make an informed decision that it then communicates to the kernel. However if that is the case, then this seems to be something that should be solved with device tree. Why are we making device tree a hard dependency here? device tree is suppose to describe the hardware in your devices. If you can not determinate your hardware by enumeration or other means, then it should be done via device tree. Seems the perfect fit here. And if I do not have device tree? so if you do not have an enumeration method for your hardware, then I assume you most likely have device tree in one form or another. And even if you really don't, nothing is stopping you from adding device tree. We have ACPI (for example) and no, it is not 5.0. It depends if the driver can determinate what the device is from ACPI. If yes, you can just load the corresponding fw image for the current device. Otherwise the ACPI can't help your problem. Thanks, Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. -Charlie On Thu, Mar 5, 2015 at 12:14 AM Ming Lei ming@canonical.com wrote: 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 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 requests based on the name of the device requesting the fw and what the filename for the fw they are requesting is, and overrides their requests with a new value. Overrides are set up by piping a description of the override into an attribute set up at /sys/class/firmware/fw_override. The string should be a null-deliminited list of the firmware name you want to over ride, the new name to replace it with, and the device name that you want the override to apply to. For example you could set up an override for a device called my_device so that any time it requests a firmware called my_fw.bin it instead gets new_fw.bin with the following command: echo -e 'my_fw.bin\0new_fw.bin\0my_device\0' /sys/class/firmware/fw_override I hate to ask, but I have to, why do you need this? We may have single driver serve several devices (a touchscreen and a touchpad) that require different firmware/config file to function. We have I remember some wifi drivers have similar usage too: one driver serves several functions, and each function need its own firmware. So looks it is fine to use different firmware name for each different function, or my understanding about the use case is wrong? Thanks, Ming Lei several options: - modify the driver to allow changing firmware name from userspace - gets old when there are several drivers that need that; - encode part numbers in the driver and request different firmware - not easily maintainable, still has an issue that same part might be used for different devices; - replace the firmware file on disk before initiating firmware load - does not work well with read-only file systems; - have udev supply different data - udev went out of fashion; - have one central place (firmware loader) that users can control to override the names - this solution. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 to a read-only partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. Regards Marcel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 to be able to update with the correct FW and detect all this at runtime due to a read-only partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. Regards Marcel I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 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 requests based on the name of the device requesting the fw and what the filename for the fw they are requesting is, and overrides their requests with a new value. Overrides are set up by piping a description of the override into an attribute set up at /sys/class/firmware/fw_override. The string should be a null-deliminited list of the firmware name you want to over ride, the new name to replace it with, and the device name that you want the override to apply to. For example you could set up an override for a device called my_device so that any time it requests a firmware called my_fw.bin it instead gets new_fw.bin with the following command: echo -e 'my_fw.bin\0new_fw.bin\0my_device\0' /sys/class/firmware/fw_override I hate to ask, but I have to, why do you need this? We may have single driver serve several devices (a touchscreen and a touchpad) that require different firmware/config file to function. We have I remember some wifi drivers have similar usage too: one driver serves several functions, and each function need its own firmware. So looks it is fine to use different firmware name for each different function, or my understanding about the use case is wrong? Thanks, Ming Lei several options: - modify the driver to allow changing firmware name from userspace - gets old when there are several drivers that need that; - encode part numbers in the driver and request different firmware - not easily maintainable, still has an issue that same part might be used for different devices; - replace the firmware file on disk before initiating firmware load - does not work well with read-only file systems; - have udev supply different data - udev went out of fashion; - have one central place (firmware loader) that users can control to override the names - this solution. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 to a read-only partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. However if that is the case, then this seems to be something that should be solved with device tree. Regards Marcel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 to be able to update with the correct FW and detect all this at runtime due to a read-only partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. Right, the drivers in question (bunch of input drivers such as elan_ts, atmel_mxt_ts, etc) might not be able to determine the proper configuration to load. Factories quite often swap pin-compatible parts and want to use the same image. Also the parts can be swapped out during RMA while keeping the same image. Userspace is able to query magnitude of sources and make an informed decision that it then communicates to the kernel. However if that is the case, then this seems to be something that should be solved with device tree. Why are we making device tree a hard dependency here? Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 therefore, needs to be able to update with the correct FW and detect all this at runtime due to a read-only partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. Right, the drivers in question (bunch of input drivers such as elan_ts, atmel_mxt_ts, etc) might not be able to determine the proper configuration to load. Factories quite often swap pin-compatible parts and want to use the same image. Also the parts can be swapped out during RMA while keeping the same image. Userspace is able to query magnitude of sources and make an informed decision that it then communicates to the kernel. However if that is the case, then this seems to be something that should be solved with device tree. Why are we making device tree a hard dependency here? device tree is suppose to describe the hardware in your devices. If you can not determinate your hardware by enumeration or other means, then it should be done via device tree. Seems the perfect fit here. And if I do not have device tree? Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 to a read-only partition (so moving the firmware binaries around isn't really an option) Here the device has only one touchscreen at a time, but it isn't known until run-time which will be present. So in this case the driver is serving the same function in each situation (running a touchscreen) but may be working with different hardware. Another situation where I've personally wanted this functionality is on a device that uses the same touch driver for both a touchscreen and a touchpad on the same device. If the driver only grabs a copy of FW from, say, /lib/firmware/touch_fw.bin then you either need to move the firmware binaries around on disk to update either device, or have a change like this that allows you to override which filename it loads. The moving option is not viable if you're using a RO filesystem. what is the actual problem here? We have drivers that load multiple firmware files and we have drivers that pick a different firmware depending on some parameters it reads from the device. Seems this is all possible already at the moment with the existing framework. You just need to update the drivers to operate properly. I totally agree, this functionality is not novel. We could have added this feature into the specific driver in question, but then we will have to do the same thing on all the other drivers we might want to do this on. I guess the real problem that this solves is by adding the change here, it allows you to override firmware names for *any* driver without having to duplicate the functionality in each one as they come up. For a specific instance, here at ChromiumOS we have devices that use Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that all can encounter this issue. The Atmel driver has a similar version of this feature baked into it but the others don't. We could add a fw_filename attribute to each of these drivers, but then it would have to be maintained across (at least) four drivers. what I am hearing here is that you can not query the hardware and figure out which manufacturer it is and with that don't know which firmware you need. Right, the drivers in question (bunch of input drivers such as elan_ts, atmel_mxt_ts, etc) might not be able to determine the proper configuration to load. Factories quite often swap pin-compatible parts and want to use the same image. Also the parts can be swapped out during RMA while keeping the same image. Userspace is able to query magnitude of sources and make an informed decision that it then communicates to the kernel. However if that is the case, then this seems to be something that should be solved with device tree. Why are we making device tree a hard dependency here? device tree is suppose to describe the hardware in your devices. If you can not determinate your hardware by enumeration or other means, then it should be done via device tree. Seems the perfect fit here. Regards Marcel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 binary to update their devices with, we > > have added the concept of a "fw override" > > > > A fw override is a rule that matches firmware requests based on the > > name of the device requesting the fw and what the filename for the > > fw they are requesting is, and overrides their requests with a new > > value. > > > > Overrides are set up by piping a description of the override into > > an attribute set up at /sys/class/firmware/fw_override. The string > > should be a null-deliminited list of the firmware name you want to > > over ride, the new name to replace it with, and the device name that > > you want the override to apply to. For example you could set up > > an override for a device called "my_device" so that any time it > > requests a firmware called "my_fw.bin" it instead gets "new_fw.bin" > > with the following command: > > > > echo -e 'my_fw.bin\0new_fw.bin\0my_device\0' > > > /sys/class/firmware/fw_override > > I hate to ask, but I have to, why do you need this? We may have single driver serve several devices (a touchscreen and a touchpad) that require different firmware/config file to function. We have several options: - modify the driver to allow changing firmware name from userspace - gets old when there are several drivers that need that; - encode part numbers in the driver and request different firmware - not easily maintainable, still has an issue that same part might be used for different devices; - replace the firmware file on disk before initiating firmware load - does not work well with read-only file systems; - have udev supply different data - udev went out of fashion; - have one central place (firmware loader) that users can control to override the names - this solution. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
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 a "fw override" > > A fw override is a rule that matches firmware requests based on the > name of the device requesting the fw and what the filename for the > fw they are requesting is, and overrides their requests with a new > value. > > Overrides are set up by piping a description of the override into > an attribute set up at /sys/class/firmware/fw_override. The string > should be a null-deliminited list of the firmware name you want to > over ride, the new name to replace it with, and the device name that > you want the override to apply to. For example you could set up > an override for a device called "my_device" so that any time it > requests a firmware called "my_fw.bin" it instead gets "new_fw.bin" > with the following command: > > echo -e 'my_fw.bin\0new_fw.bin\0my_device\0' > > /sys/class/firmware/fw_override I hate to ask, but I have to, why do you need this? Also, this needs to be documented somewhere, Documentation/ABI/ please? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] firmware_class: Add firmware filename overrides
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 requests based on the
name of the device requesting the fw and what the filename for the
fw they are requesting is, and overrides their requests with a new
value.
Overrides are set up by piping a description of the override into
an attribute set up at /sys/class/firmware/fw_override. The string
should be a null-deliminited list of the firmware name you want to
over ride, the new name to replace it with, and the device name that
you want the override to apply to. For example you could set up
an override for a device called "my_device" so that any time it
requests a firmware called "my_fw.bin" it instead gets "new_fw.bin"
with the following command:
echo -e 'my_fw.bin\0new_fw.bin\0my_device\0' >
/sys/class/firmware/fw_override
The device name is an optional field, and if no string is there it
will apply to ANY device requesting a firmware of that name. For
example if you want all devices looking for my_fw.bin to get
new_fw.bin instead you might use this command:
echo -e 'my_fw.bin\0new_fw.bin\0\0' > /sys/class/firmware/fw_override
Existing overrides can be viewed by cat-ing that attribute and can
be overwritten with new rules at will.
To delete an override simply put an empty string in the new firmware
field and the matching rule will be removed. eg: to remove the rule
set up in the first above example, one might run this command.
echo -e 'my_fw.bin\0\0my_device\0' > /sys/class/firmware/fw_override
Note: To make this feature usable even when CONFIG_FW_LOADER_USER_HELPER
is not set, the firmware class is brought back. However, "timeout"
and the other functionality remain disabled.
Signed-off-by: Charlie Mooney
---
drivers/base/firmware_class.c | 196 ++
1 file changed, 180 insertions(+), 16 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 6c5c9ed..863ced5 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -440,6 +440,163 @@ static int fw_add_devm_name(struct device *dev, const
char *name)
}
#endif
+struct fw_override {
+ struct list_head node;
+ const char *old_name;
+ const char *new_name;
+ const char *device_name;
+};
+static LIST_HEAD(fw_override_list);
+
+/*
+ * find_fw_override -- Find the override for the fw name and device specified
+ *
+ * Given a fw filename and the devices's name, this function finds the fw
+ * override assigned to it (if one exists).
+ *
+ * Returns a pointer to the fw_override struct in question or NULL if it
+ * does not exist.
+ */
+static struct fw_override *find_fw_override(const char *fw_name,
+const char *device_name)
+{
+ struct fw_override *override;
+
+ if (!fw_name)
+ return NULL;
+
+ list_for_each_entry(override, _override_list, node) {
+ if (!strcmp(override->old_name, fw_name) &&
+ (!device_name ||
+!strcmp(device_name, override->device_name))) {
+ return override;
+ }
+ }
+ return NULL;
+}
+
+/* Determine what is the actual filename that should be loaded for a given
+ * firmware and device. If there is no overrides in place for this device
+ * and firmware, then the name will be returned unchanged. Otherwise, the
+ * overridden firmware name is returned.
+ *
+ * This is called from _request_firmware() to make sure that overrides are
+ * applied to every firmware request regardless of how the request is made.
+ */
+static const char *firmware_overridden_name(const char *name,
+ struct device *device)
+{
+ struct fw_override *override;
+
+ /* Check first for device-specific overrides, before checking for more
+* generic overrides that might apply to this device.
+*/
+ override = find_fw_override(name, dev_name(device));
+ if (!override)
+ override = find_fw_override(name, NULL);
+
+ if (override)
+ dev_info(device, "firmware: '%s' overridden to '%s'.\n",
+ name, override->new_name);
+
+ return override ? override->new_name : name;
+}
+
+
+/*
+ * delete_fw_override -- Remove an override for the fw
+ *
+ * Given a firmware filename and the device name, remove any overrides that may
+ * have been set for it. If the device name is NULL, then this looks only for
+ * global overrides.
+ */
+static void delete_fw_override(const char *fw_name, const char *device_name)
+{
+ struct fw_override *to_delete;
+
+ to_delete = find_fw_override(fw_name, device_name);
+
Re: [PATCH] firmware_class: Add firmware filename overrides
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 binary to update their devices with, we have added the concept of a fw override A fw override is a rule that matches firmware requests based on the name of the device requesting the fw and what the filename for the fw they are requesting is, and overrides their requests with a new value. Overrides are set up by piping a description of the override into an attribute set up at /sys/class/firmware/fw_override. The string should be a null-deliminited list of the firmware name you want to over ride, the new name to replace it with, and the device name that you want the override to apply to. For example you could set up an override for a device called my_device so that any time it requests a firmware called my_fw.bin it instead gets new_fw.bin with the following command: echo -e 'my_fw.bin\0new_fw.bin\0my_device\0' /sys/class/firmware/fw_override I hate to ask, but I have to, why do you need this? We may have single driver serve several devices (a touchscreen and a touchpad) that require different firmware/config file to function. We have several options: - modify the driver to allow changing firmware name from userspace - gets old when there are several drivers that need that; - encode part numbers in the driver and request different firmware - not easily maintainable, still has an issue that same part might be used for different devices; - replace the firmware file on disk before initiating firmware load - does not work well with read-only file systems; - have udev supply different data - udev went out of fashion; - have one central place (firmware loader) that users can control to override the names - this solution. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] firmware_class: Add firmware filename overrides
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 requests based on the
name of the device requesting the fw and what the filename for the
fw they are requesting is, and overrides their requests with a new
value.
Overrides are set up by piping a description of the override into
an attribute set up at /sys/class/firmware/fw_override. The string
should be a null-deliminited list of the firmware name you want to
over ride, the new name to replace it with, and the device name that
you want the override to apply to. For example you could set up
an override for a device called my_device so that any time it
requests a firmware called my_fw.bin it instead gets new_fw.bin
with the following command:
echo -e 'my_fw.bin\0new_fw.bin\0my_device\0'
/sys/class/firmware/fw_override
The device name is an optional field, and if no string is there it
will apply to ANY device requesting a firmware of that name. For
example if you want all devices looking for my_fw.bin to get
new_fw.bin instead you might use this command:
echo -e 'my_fw.bin\0new_fw.bin\0\0' /sys/class/firmware/fw_override
Existing overrides can be viewed by cat-ing that attribute and can
be overwritten with new rules at will.
To delete an override simply put an empty string in the new firmware
field and the matching rule will be removed. eg: to remove the rule
set up in the first above example, one might run this command.
echo -e 'my_fw.bin\0\0my_device\0' /sys/class/firmware/fw_override
Note: To make this feature usable even when CONFIG_FW_LOADER_USER_HELPER
is not set, the firmware class is brought back. However, timeout
and the other functionality remain disabled.
Signed-off-by: Charlie Mooney charliemoo...@chromium.org
---
drivers/base/firmware_class.c | 196 ++
1 file changed, 180 insertions(+), 16 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 6c5c9ed..863ced5 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -440,6 +440,163 @@ static int fw_add_devm_name(struct device *dev, const
char *name)
}
#endif
+struct fw_override {
+ struct list_head node;
+ const char *old_name;
+ const char *new_name;
+ const char *device_name;
+};
+static LIST_HEAD(fw_override_list);
+
+/*
+ * find_fw_override -- Find the override for the fw name and device specified
+ *
+ * Given a fw filename and the devices's name, this function finds the fw
+ * override assigned to it (if one exists).
+ *
+ * Returns a pointer to the fw_override struct in question or NULL if it
+ * does not exist.
+ */
+static struct fw_override *find_fw_override(const char *fw_name,
+const char *device_name)
+{
+ struct fw_override *override;
+
+ if (!fw_name)
+ return NULL;
+
+ list_for_each_entry(override, fw_override_list, node) {
+ if (!strcmp(override-old_name, fw_name)
+ (!device_name ||
+!strcmp(device_name, override-device_name))) {
+ return override;
+ }
+ }
+ return NULL;
+}
+
+/* Determine what is the actual filename that should be loaded for a given
+ * firmware and device. If there is no overrides in place for this device
+ * and firmware, then the name will be returned unchanged. Otherwise, the
+ * overridden firmware name is returned.
+ *
+ * This is called from _request_firmware() to make sure that overrides are
+ * applied to every firmware request regardless of how the request is made.
+ */
+static const char *firmware_overridden_name(const char *name,
+ struct device *device)
+{
+ struct fw_override *override;
+
+ /* Check first for device-specific overrides, before checking for more
+* generic overrides that might apply to this device.
+*/
+ override = find_fw_override(name, dev_name(device));
+ if (!override)
+ override = find_fw_override(name, NULL);
+
+ if (override)
+ dev_info(device, firmware: '%s' overridden to '%s'.\n,
+ name, override-new_name);
+
+ return override ? override-new_name : name;
+}
+
+
+/*
+ * delete_fw_override -- Remove an override for the fw
+ *
+ * Given a firmware filename and the device name, remove any overrides that may
+ * have been set for it. If the device name is NULL, then this looks only for
+ * global overrides.
+ */
+static void delete_fw_override(const char *fw_name, const char *device_name)
+{
+ struct fw_override *to_delete;
+
+ to_delete = find_fw_override(fw_name, device_name);
+
Re: [PATCH] firmware_class: Add firmware filename overrides
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 a fw override A fw override is a rule that matches firmware requests based on the name of the device requesting the fw and what the filename for the fw they are requesting is, and overrides their requests with a new value. Overrides are set up by piping a description of the override into an attribute set up at /sys/class/firmware/fw_override. The string should be a null-deliminited list of the firmware name you want to over ride, the new name to replace it with, and the device name that you want the override to apply to. For example you could set up an override for a device called my_device so that any time it requests a firmware called my_fw.bin it instead gets new_fw.bin with the following command: echo -e 'my_fw.bin\0new_fw.bin\0my_device\0' /sys/class/firmware/fw_override I hate to ask, but I have to, why do you need this? Also, this needs to be documented somewhere, Documentation/ABI/ please? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
