Dan Williams <dcbw@xxxxxxxxxx> writes:
>> Wasn't the concensus that request_firmware() will be used for this
>> kind of device specific data? stlc45xx had a similar sysfs interface
>> and people didn't like it. And I tend to agree with them, adding odd
>> sysfs files is not the best way to handle this.
>
> It could be yes, but what would the trigger to upload the new firmware
> be? A /standard/ sysfs file that you
>
> echo "new-firmware-v345" > eeprom_write
>
> into that would then request_firmware("new-firmware-v345")?
To be sure that we are talking about the same stuff, let's clarify
this a bit first. There are two different use cases where eeprom from
user space is needed:
Category 1. Devices which don't have eeprom at all and require the
user space provides the eeprom data during every device
boot. These devices won't even function correctly if they
don't get the correct eeprom data from user space. As an
example, grep nvs from wl12xx.
Category 2. Devices which have eeprom but can be updated by user.
So we have two separate problems here.
For category 1 devices request_firmware() was proposed earlier and for
category 2 the ethtool support you mentioned sounds like a viable
option.
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
