Message ID | 19897.11321.556139.837633@gargle.gargle.HOWL (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
On Thursday 28 April 2011 10:58:33 Sujith wrote: > From: Sujith Manoharan <Sujith.Manoharan@atheros.com> > > Debugfs file location: <debugfs_mnt>/ieee80211/phy#/ath9k_htc/base_eeprom > If you just want to dump the eeprom, then why not with a userspace utility? It's pretty easy to write such a thing with libusb, furthermore it's more versatile and portable so the *BSD-folks are not left out! Regards, Chr -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 29 April 2011 07:16, Christian Lamparter <chunkeey@googlemail.com> wrote: > If you just want to dump the eeprom, then why not with a userspace utility? > It's pretty easy to write such a thing with libusb, furthermore it's more > versatile and portable so the *BSD-folks are not left out! I've written a replacement set of userspace tools in freebsd which take a raw eeprom dump from the HAL diag API and print out a v14/v4k eeprom dump. It isn't pretty but it works. There were existing tools for the earlier EEPROM formats but they worked directly from the diag API rather than an intermediary dump file. This way users can email me a text dump and I can check/parse it myself. Adrian -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Christian Lamparter wrote: > On Thursday 28 April 2011 10:58:33 Sujith wrote: > > From: Sujith Manoharan <Sujith.Manoharan@atheros.com> > > > > Debugfs file location: <debugfs_mnt>/ieee80211/phy#/ath9k_htc/base_eeprom > > > If you just want to dump the eeprom, then why not with a userspace utility? > It's pretty easy to write such a thing with libusb, furthermore it's more > versatile and portable so the *BSD-folks are not left out! We do have an eeprom dump tool for PCI cards, but hardly any one uses that. It's much more convenient to use debugging features that are present in the driver itself. On an embedded board, it makes things a little bit easier. And BSD ? BSD is dead. Adrian is just deluded. :-) Sujith -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 29 April 2011 09:19, Sujith <m.sujith@gmail.com> wrote:
> And BSD ? BSD is dead. Adrian is just deluded. :-)
I know. There's even a commit to ath9k from me that obviously indicates that. :)
But in all seriousness, I just wrote a few tools for BSD that:
* take a dump of the EEPROM via the HAL diag API and write it to a
text file, so it can be copied around as needed;
* take a text dump of an EEPROM and decode it, for v14/v4k EEPROM
formats. I'm about to do one up for the AR9287 when I drop in support
for that.
Adrian
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 29 April 2011 03:19:21 Sujith wrote: > Christian Lamparter wrote: > > On Thursday 28 April 2011 10:58:33 Sujith wrote: > > > From: Sujith Manoharan <Sujith.Manoharan@atheros.com> > > > > > > Debugfs file location: <debugfs_mnt>/ieee80211/phy#/ath9k_htc/base_eeprom > > > > > If you just want to dump the eeprom, then why not with a userspace utility? > > It's pretty easy to write such a thing with libusb, furthermore it's more > > versatile and portable so the *BSD-folks are not left out! > > We do have an eeprom dump tool for PCI cards, but hardly any one uses > that. Oh, I used ath_info for ath5k a lot. Especially to get around regdom restrictions. Sure, your tool won't be able to do that, but never the less. > It's much more convenient to use debugging features that are present > in the driver itself. On an embedded board, it makes things a little bit easier. Do you really think that everyone will be happy to recompile their stripped & heavily customised embedded kernels/or compat-wireless just to enable DEBUG and waste precious resources? Even with a PC, this is not necessarily straightforward, especially if the user has never done it before. Regards, Chr -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Christian Lamparter wrote: > Do you really think that everyone will be happy to recompile their stripped & heavily > customised embedded kernels/or compat-wireless just to enable DEBUG and > waste precious resources? Even with a PC, this is not necessarily straightforward, > especially if the user has never done it before. Yeah, this was the reasoning that I used to write a tool to dump eeprom data for PCI cards (using libpciaccess), and it is languishing internally. :) I agree that there are benefits to having a userspace tool, maybe Luis' ath-utils tree can be used. But until then, it would be useful to have these in the driver. Sujith -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Apr 29, 2011 at 02:54:17AM -0700, Sujith wrote: > Christian Lamparter wrote: > > Do you really think that everyone will be happy to recompile their stripped & heavily > > customised embedded kernels/or compat-wireless just to enable DEBUG and > > waste precious resources? Even with a PC, this is not necessarily straightforward, > > especially if the user has never done it before. > > Yeah, this was the reasoning that I used to write a tool to dump eeprom > data for PCI cards (using libpciaccess), and it is languishing internally. :) > > I agree that there are benefits to having a userspace tool, > maybe Luis' ath-utils tree can be used. But until then, it would be useful > to have these in the driver. Why didn't we ever open your tool up? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_debug.c b/drivers/net/wireless/ath/ath9k/htc_drv_debug.c index 894e5ef..cff2d21 100644 --- a/drivers/net/wireless/ath/ath9k/htc_drv_debug.c +++ b/drivers/net/wireless/ath/ath9k/htc_drv_debug.c @@ -492,6 +492,158 @@ static const struct file_operations fops_debug = { .llseek = default_llseek, }; +static ssize_t read_file_base_eeprom(struct file *file, char __user *user_buf, + size_t count, loff_t *ppos) +{ + struct ath9k_htc_priv *priv = file->private_data; + struct ath_common *common = ath9k_hw_common(priv->ah); + struct base_eep_header *pBase = NULL; + unsigned int len = 0, size = 1500; + ssize_t retval = 0; + char *buf; + + /* + * This can be done since all the 3 EEPROM families have the + * same base header upto a certain point, and we are interested in + * the data only upto that point. + */ + + if (AR_SREV_9271(priv->ah)) + pBase = (struct base_eep_header *) + &priv->ah->eeprom.map4k.baseEepHeader; + else if (priv->ah->hw_version.usbdev == AR9280_USB) + pBase = (struct base_eep_header *) + &priv->ah->eeprom.def.baseEepHeader; + else if (priv->ah->hw_version.usbdev == AR9287_USB) + pBase = (struct base_eep_header *) + &priv->ah->eeprom.map9287.baseEepHeader; + + if (pBase == NULL) { + ath_err(common, "Unknown EEPROM type\n"); + return 0; + } + + buf = kzalloc(size, GFP_KERNEL); + if (buf == NULL) + return -ENOMEM; + + len += snprintf(buf + len, size - len, + "%20s : %10d\n", "Major Version", + pBase->version >> 12); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", "Minor Version", + pBase->version & 0xFFF); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", "Checksum", + pBase->checksum); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", "Length", + pBase->length); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", "RegDomain1", + pBase->regDmn[0]); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", "RegDomain2", + pBase->regDmn[1]); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", + "TX Mask", pBase->txMask); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", + "RX Mask", pBase->rxMask); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", + "Allow 5GHz", + !!(pBase->opCapFlags & AR5416_OPFLAGS_11A)); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", + "Allow 2GHz", + !!(pBase->opCapFlags & AR5416_OPFLAGS_11G)); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", + "Disable 2GHz HT20", + !!(pBase->opCapFlags & AR5416_OPFLAGS_N_2G_HT20)); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", + "Disable 2GHz HT40", + !!(pBase->opCapFlags & AR5416_OPFLAGS_N_2G_HT40)); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", + "Disable 5Ghz HT20", + !!(pBase->opCapFlags & AR5416_OPFLAGS_N_5G_HT20)); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", + "Disable 5Ghz HT40", + !!(pBase->opCapFlags & AR5416_OPFLAGS_N_5G_HT40)); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", + "Big Endian", + !!(pBase->eepMisc & 0x01)); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", + "Cal Bin Major Ver", + (pBase->binBuildNumber >> 24) & 0xFF); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", + "Cal Bin Minor Ver", + (pBase->binBuildNumber >> 16) & 0xFF); + len += snprintf(buf + len, size - len, + "%20s : %10d\n", + "Cal Bin Build", + (pBase->binBuildNumber >> 8) & 0xFF); + + /* + * UB91 specific data. + */ + if (AR_SREV_9271(priv->ah)) { + struct base_eep_header_4k *pBase4k = + &priv->ah->eeprom.map4k.baseEepHeader; + + len += snprintf(buf + len, size - len, + "%20s : %10d\n", + "TX Gain type", + pBase4k->txGainType); + } + + /* + * UB95 specific data. + */ + if (priv->ah->hw_version.usbdev == AR9287_USB) { + struct base_eep_ar9287_header *pBase9287 = + &priv->ah->eeprom.map9287.baseEepHeader; + + len += snprintf(buf + len, size - len, + "%20s : %10ddB\n", + "Power Table Offset", + pBase9287->pwrTableOffset); + + len += snprintf(buf + len, size - len, + "%20s : %10d\n", + "OpenLoop Power Ctrl", + pBase9287->openLoopPwrCntl); + } + + len += snprintf(buf + len, size - len, + "%20s : %02X:%02X:%02X:%02X:%02X:%02X\n", + "MacAddress", + pBase->macAddr[0], pBase->macAddr[1], pBase->macAddr[2], + pBase->macAddr[3], pBase->macAddr[4], pBase->macAddr[5]); + if (len > size) + len = size; + + retval = simple_read_from_buffer(user_buf, count, ppos, buf, len); + kfree(buf); + + return retval; +} + +static const struct file_operations fops_base_eeprom = { + .read = read_file_base_eeprom, + .open = ath9k_debugfs_open, + .owner = THIS_MODULE, + .llseek = default_llseek, +}; + int ath9k_htc_init_debug(struct ath_hw *ah) { struct ath_common *common = ath9k_hw_common(ah); @@ -503,21 +655,23 @@ int ath9k_htc_init_debug(struct ath_hw *ah) return -ENOMEM; debugfs_create_file("tgt_int_stats", S_IRUSR, priv->debug.debugfs_phy, - priv, &fops_tgt_int_stats); + priv, &fops_tgt_int_stats); debugfs_create_file("tgt_tx_stats", S_IRUSR, priv->debug.debugfs_phy, - priv, &fops_tgt_tx_stats); + priv, &fops_tgt_tx_stats); debugfs_create_file("tgt_rx_stats", S_IRUSR, priv->debug.debugfs_phy, - priv, &fops_tgt_rx_stats); + priv, &fops_tgt_rx_stats); debugfs_create_file("xmit", S_IRUSR, priv->debug.debugfs_phy, - priv, &fops_xmit); + priv, &fops_xmit); debugfs_create_file("recv", S_IRUSR, priv->debug.debugfs_phy, - priv, &fops_recv); + priv, &fops_recv); debugfs_create_file("slot", S_IRUSR, priv->debug.debugfs_phy, - priv, &fops_slot); + priv, &fops_slot); debugfs_create_file("queue", S_IRUSR, priv->debug.debugfs_phy, - priv, &fops_queue); + priv, &fops_queue); debugfs_create_file("debug", S_IRUSR | S_IWUSR, priv->debug.debugfs_phy, - priv, &fops_debug); + priv, &fops_debug); + debugfs_create_file("base_eeprom", S_IRUSR, priv->debug.debugfs_phy, + priv, &fops_base_eeprom); return 0; }