All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Lamparter <chunkeey@googlemail.com>
To: Kalle Valo <kalle.valo@iki.fi>
Cc: linux-wireless@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@gmail.com>,
	Dan Williams <dcbw@redhat.com>
Subject: Re: [RFC] p54: software hot-swap eeprom image
Date: Sat, 21 Nov 2009 00:33:49 +0100	[thread overview]
Message-ID: <200911210033.49887.chunkeey@googlemail.com> (raw)
In-Reply-To: <87y6m1aqro.fsf@purkki.valot.fi>

On Friday 20 November 2009 21:24:27 Kalle Valo wrote:
> Christian Lamparter <chunkeey@googlemail.com> 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.

no, I wanted something that could fix every possible problem.

I know of several different devices which could use more or
less the same fixes, but we want to retain the mac-addresses, 
baseband/mac processor info, PHYs and hw-layout related features
(or in other words: 95% of the eeprom _other_ content).

Here's *real* list of the problems:
p54pci devices:
1. CardBus Netgear WG511 (duette phy / ISL3880 mac)
		- (no country code)
		- (disabled antenna diversity)
		- *swapped rssi<->dbm parameters*
		  => affects internal calibration and link stability,
			 renders dBm reading totally useless,

2. miniPCI ZComax XG-601 (frisbee phy / ISL3880 mac)
		- (no country code)
		- (disabled antenna diversity)

3. miniPCI ZComax XG-603 (frisbee phy / ISL3886 mac)
		- (no country code)
		- (disabled antenna diversity)
		- *fixed* output power limits
		  (the card _only_ transmits @ 14 dBm)

4. miniPCI Allnet 271 (frisbee phy / ISL3880 mac)
		- (no country code)
		- (disabled antenna diversity)

5. James' minipci Gigafast WF728-AEX (frisbee phy / isl3880 mac)
		- (no country code)
		- (disabled antenna diversity)
		- incomplete phy calibration data
		  => card only works on channel 1, 7, 12, 14

p54usb devices:
1. Dell 1450 USB (crossbow phy / ISL3892 mac)
		- *wrong* country code
		  (disables all non-US channels, even though it's OK to use them in the EU)
	   	- disabled antenna diversity

Or in other words, I haven't come a cross a single p54 device with
a proper EEPROM since I picked up my first card 3/4 years ago...

anyway, I had to think about it again:
eeprom_overwrite is no longer meant to fully replace the onboard eeprom, or
in p54spi's case the supplied (minimal) blob data. It should (not yet, but
hopefully in the next RFC, if we all agree on something) merely allow
users to fix the faulty pieces without altering the unaffected bits 
(like volatile patch deltas for the static const eeprom).
In fact I gave it a new name already: volatile_eeprom_patch :-D .

I'm unsure about ethtool --eeprom-load. Because unlike --change-eeprom,
we won't be able to mess around with low-level physical bits flipping
in the EEPROM itself, so people might get confused why they _setting_
doesn't stick over modules reloads/reboots etc...

Regards,
	Chr

---
damn bugs!

      parent reply	other threads:[~2009-11-20 23:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-20 19:27 [RFC] p54: software hot-swap eeprom image Christian Lamparter
2009-11-20 19:53 ` Dan Williams
2009-11-20 20:32   ` Luis R. Rodriguez
2009-11-20 20:32     ` Luis R. Rodriguez
2009-11-20 20:32   ` Kalle Valo
2009-11-20 20:24 ` Kalle Valo
2009-11-20 20:48   ` Dan Williams
2009-11-20 21:02     ` Kalle Valo
2009-11-20 23:12       ` Dan Williams
2009-11-20 23:33   ` Christian Lamparter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200911210033.49887.chunkeey@googlemail.com \
    --to=chunkeey@googlemail.com \
    --cc=dcbw@redhat.com \
    --cc=kalle.valo@iki.fi \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mcgrof@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.