Subject: A generic kernel compatibilty code - msg#01545

Previous Message by Date: click to view message preview

Re: [RFC] p54: software hot-swap eeprom image

Dan Williams <dcbw@xxxxxxxxxx> writes: > On Fri, 2009-11-20 at 20:27 +0100, Christian Lamparter wrote: >> This (aggregated) patch adds a new sysfs file "eeprom_overwrite" >> which can be used to upload an customized eeprom image to the >> driver during normal operation. [...] > Honestly I wonder if this would be better done with ethtool. There's > already ethtool --eeprom-dump, would it be so hard to do an ethtool > --eeprom-load ? > > I can see a number of devices doing this, so in my mind it makes sense > to have a generic facility for this sort of thing. But then again it's > not so common an operation and its fraught with danger :) I think that devices without eeprom at all (eg. stlc4550, most wl1251 and all wl1271 chips) request_firmware() and a udev script is the best way to go, as they will need the eeprom data from user space during every boot. This was discussed few months back, but unfortunately I have yet to seen an implementation of this :) Hopefully I find some time to try this soon. But for devices with eeprom, having support in ethtool sounds good to me. > Libertas could potentially use this, but libertas has *two* EEPROM > images that it might need to update. So if ethtool did grow > --eeprom-load we may want to account for more than one eeprom image. Makes sense to mee. -- 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

Next Message by Date: click to view message preview

Re: [RFC] p54: software hot-swap eeprom image

On Fri, 2009-11-20 at 22:24 +0200, Kalle Valo wrote: > Christian Lamparter <chunkeey@xxxxxxxxxxxxxx> writes: > > > This (aggregated) patch adds a new sysfs file "eeprom_overwrite" > > which can be used to upload an customized eeprom image to the > > driver during normal operation. > > > > The old wlanX device will quickly vanish. And if the new EEPROM > > image passes all sanity checks the device will reappear. > > > > Hopefully, this proves to be an adequate solution for everyone > > with a bad/missing EEPROM data/chip. > > 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")? I don't really care where read/write functionality is, I just want this stuff to be in one place and not have one mechanism for reading it and a few different ones for writing it. Dan -- 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

Previous Message by Thread: click to view message preview

[PATCH 00/19] iwlwifi updates 11/20/2009

This series includes various fixes and cleanup. Driver is now able to do single byte writes to treat registers with single-byte fields correctly and not rely on execution order. A previous patch "iwlwifi: separate led function from statistic notification" broke LEDs on 3945. This is now fixed. Some more LED cleanup is also included. More work surrounding SM PS is included. debugfs received some attention with files now having correct permissions, all TX queue information can now be displayed, memory for display of sram contents is now dynamically allocated, and if a user did not specify the offset and length when dumping sram contents then the entire data portion will be printed. It is now possible to separate IO tracing to reduce amount of data. The pci ids of 5000 series is updated to reflect what is in production. A uCode error log as well as portion of the event log is now always printed when a problem occurs, user does not need to set debug flags. Driver now informs uCode promptly when disassociated to prevent uCode from sending data to AP. "iwlwifi: no need to set use_rts_for_ht for BG device" fixes a merge problem that is present in wireless-testing but not in wireless-next-2.6 Ben M Cahill (2): iwlwifi: Add iwl_write8() iwlagn: Use iwl_write8() for CSR_INT_COALESCING register Jay Sternberg (1): iwlwifi: Tell the ucode immediately when association state changes Johannes Berg (1): iwlwifi: separate IO tracing Reinette Chatre (2): iwl3945: removed unused struct and definitions iwlwifi: no need to set use_rts_for_ht for BG device Wey-Yi Guy (13): iwlwifi: control led while update tx/rx bytes counts iwlwifi: set sm_ps_mode as part of cfg parameters iwlwifi: reset led_tpt when clear tx/rx traffic byte counts iwlwifi: set read/write permission for debugfs files iwlwifi: increase tx_queue debugfs buffer size iwlwifi: dynamically allocate buffer for sram debugfs file iwlwifi: fix reserved2 field in iwl4965_addsta iwlwifi: update supported PCI_ID list for 5xx0 series iwlwifi: by default, dump entire sram data portion iwlwifi: dump error log when uCode error occurred iwlwifi: print limited number of event log when uCode error iwlwifi: change message for cmd queue full error iwlwifi: remove reset led_tpt from iwl_leds_init() drivers/net/wireless/iwlwifi/iwl-1000.c | 2 +- drivers/net/wireless/iwlwifi/iwl-3945.h | 11 +-- drivers/net/wireless/iwlwifi/iwl-4965.c | 3 +- drivers/net/wireless/iwlwifi/iwl-5000.c | 33 +++++- drivers/net/wireless/iwlwifi/iwl-6000.c | 4 +- drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 8 +- drivers/net/wireless/iwlwifi/iwl-agn.c | 174 ++++++++++++++++++++------- drivers/net/wireless/iwlwifi/iwl-core.c | 76 ++++++------ drivers/net/wireless/iwlwifi/iwl-core.h | 22 +--- drivers/net/wireless/iwlwifi/iwl-csr.h | 4 +- drivers/net/wireless/iwlwifi/iwl-debug.h | 3 +- drivers/net/wireless/iwlwifi/iwl-debugfs.c | 125 ++++++++++---------- drivers/net/wireless/iwlwifi/iwl-dev.h | 12 +-- drivers/net/wireless/iwlwifi/iwl-devtrace.c | 1 + drivers/net/wireless/iwlwifi/iwl-devtrace.h | 21 +++- drivers/net/wireless/iwlwifi/iwl-io.h | 20 +++ drivers/net/wireless/iwlwifi/iwl-led.c | 1 - drivers/net/wireless/iwlwifi/iwl-rx.c | 3 +- drivers/net/wireless/iwlwifi/iwl-tx.c | 2 +- drivers/net/wireless/iwlwifi/iwl3945-base.c | 74 ++++++++++-- 20 files changed, 395 insertions(+), 204 deletions(-) -- 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

Next Message by Thread: click to view message preview

Re: A generic kernel compatibilty code

On Fri, Nov 20, 2009 at 12:45 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote: > Everyone and their mother reinvents the wheel when it comes to > backporting kernel modules. It a painful job and it seems to me an > alternative is possible. If we can write generic compatibilty code for > a new routine introduced on the next kernel how about just merging it > to the kernel under some generic compat module. This would be > completey ignored by everyone using the stable kernel but can be > copied by anyone doing backport work. > > So I'm thinking something as simple as a generic compat/comat.ko with > compat-2.6.32.[ch] files. FWIW, I meant a compat-2.6.32.[ch] and compat-2.6.31.[ch] and so on. All these would link to the compat.ko Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/