From: Sujith Manoharan <[email protected]>
Debugfs file location: <debugfs_mnt>/ieee80211/phy#/ath9k_htc/base_eeprom
Signed-off-by: Sujith Manoharan <[email protected]>
---
drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 170 ++++++++++++++++++++++-
1 files changed, 162 insertions(+), 8 deletions(-)
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;
}
--
1.7.4.4
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 <[email protected]>
> > >
> > > 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
On 29 April 2011 07:16, Christian Lamparter <[email protected]> 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
On Thursday 28 April 2011 10:58:33 Sujith wrote:
> From: Sujith Manoharan <[email protected]>
>
> 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
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
On 29 April 2011 09:19, Sujith <[email protected]> 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
Christian Lamparter wrote:
> On Thursday 28 April 2011 10:58:33 Sujith wrote:
> > From: Sujith Manoharan <[email protected]>
> >
> > 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
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