Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

2017-03-24 Thread Christian Lamparter 
On Thursday, March 23, 2017 3:43:28 PM CET Alban wrote:
> On Tue, 14 Mar 2017 00:53:55 +0100
> Christian Lamparter  wrote:
> 
> > On Monday, March 13, 2017 10:05:11 PM CET Alban wrote:
> > > Currently SoC platforms use a firmware request to get the EEPROM data.
> > > This is mostly a hack and rely on using a user-helper scripts which is
> > > deprecated. A nicer alternative is to use the nvmem API which was
> > > designed for this kind of task.
> > > 
> > > Furthermore we let CONFIG_ATH9K_AHB select CONFIG_NVMEM as such
> > > devices will generally use this method for loading the EEPROM data.
> > > 
> > > Signed-off-by: Alban 
> > > ---
> > > @@ -654,6 +656,25 @@ static int ath9k_init_softc(u16 devid, struct 
> > > ath_softc *sc,
> > >   if (ret)
> > >   return ret;
> > >  
> > > + /* If the EEPROM hasn't been retrieved via firmware request
> > > +  * use the nvmem API insted.
> > > +  */
> > > + if (!ah->eeprom_blob) {
> > > + struct nvmem_cell *eeprom_cell;
> > > +
> > > + eeprom_cell = nvmem_cell_get(ah->dev, "eeprom");
> > > + if (!IS_ERR(eeprom_cell)) {
> > > + ah->eeprom_data = nvmem_cell_read(
> > > + eeprom_cell, >eeprom_size);
> > > + nvmem_cell_put(eeprom_cell);
> > > +
> > > + if (IS_ERR(ah->eeprom_data)) {
> > > + dev_err(ah->dev, "failed to read eeprom");
> > > + return PTR_ERR(ah->eeprom_data);
> > > + }
> > > + }
> > > + }
> > > +
> > >   if (ath9k_led_active_high != -1)
> > >   ah->config.led_active_high = ath9k_led_active_high == 1;
> > >
> > Are you sure this works with AR93XX SoCs that have the calibration data
> > in the OTP?
> 
> I only tested this on an ar9132 platform, so it might well be that a
> few things are missing for the newer SoC. However this shouldn't break
> anything existing as a platform needs to define an nvmem cell on the
> athk9 device for this code to be used a all.

Yes, I looked at it.
+   eeprom_cell = nvmem_cell_get(ah->dev, "eeprom");
+   if (!IS_ERR(eeprom_cell)) {
+   ...
+   }
So if there's a error with the "eeprom" nvmem property,
(i.e.: it's not present) the driver should works as before.

Thanks,
Christian

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

2017-03-24 Thread Christian Lamparter 
On Thursday, March 23, 2017 3:43:28 PM CET Alban wrote:
> On Tue, 14 Mar 2017 00:53:55 +0100
> Christian Lamparter  wrote:
> 
> > On Monday, March 13, 2017 10:05:11 PM CET Alban wrote:
> > > Currently SoC platforms use a firmware request to get the EEPROM data.
> > > This is mostly a hack and rely on using a user-helper scripts which is
> > > deprecated. A nicer alternative is to use the nvmem API which was
> > > designed for this kind of task.
> > > 
> > > Furthermore we let CONFIG_ATH9K_AHB select CONFIG_NVMEM as such
> > > devices will generally use this method for loading the EEPROM data.
> > > 
> > > Signed-off-by: Alban 
> > > ---
> > > @@ -654,6 +656,25 @@ static int ath9k_init_softc(u16 devid, struct 
> > > ath_softc *sc,
> > >   if (ret)
> > >   return ret;
> > >  
> > > + /* If the EEPROM hasn't been retrieved via firmware request
> > > +  * use the nvmem API insted.
> > > +  */
> > > + if (!ah->eeprom_blob) {
> > > + struct nvmem_cell *eeprom_cell;
> > > +
> > > + eeprom_cell = nvmem_cell_get(ah->dev, "eeprom");
> > > + if (!IS_ERR(eeprom_cell)) {
> > > + ah->eeprom_data = nvmem_cell_read(
> > > + eeprom_cell, >eeprom_size);
> > > + nvmem_cell_put(eeprom_cell);
> > > +
> > > + if (IS_ERR(ah->eeprom_data)) {
> > > + dev_err(ah->dev, "failed to read eeprom");
> > > + return PTR_ERR(ah->eeprom_data);
> > > + }
> > > + }
> > > + }
> > > +
> > >   if (ath9k_led_active_high != -1)
> > >   ah->config.led_active_high = ath9k_led_active_high == 1;
> > >
> > Are you sure this works with AR93XX SoCs that have the calibration data
> > in the OTP?
> 
> I only tested this on an ar9132 platform, so it might well be that a
> few things are missing for the newer SoC. However this shouldn't break
> anything existing as a platform needs to define an nvmem cell on the
> athk9 device for this code to be used a all.

Yes, I looked at it.
+   eeprom_cell = nvmem_cell_get(ah->dev, "eeprom");
+   if (!IS_ERR(eeprom_cell)) {
+   ...
+   }
So if there's a error with the "eeprom" nvmem property,
(i.e.: it's not present) the driver should works as before.

Thanks,
Christian

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

2017-03-23 Thread Alban 
On Tue, 14 Mar 2017 00:53:55 +0100
Christian Lamparter  wrote:

> On Monday, March 13, 2017 10:05:11 PM CET Alban wrote:
> > Currently SoC platforms use a firmware request to get the EEPROM data.
> > This is mostly a hack and rely on using a user-helper scripts which is
> > deprecated. A nicer alternative is to use the nvmem API which was
> > designed for this kind of task.
> > 
> > Furthermore we let CONFIG_ATH9K_AHB select CONFIG_NVMEM as such
> > devices will generally use this method for loading the EEPROM data.
> > 
> > Signed-off-by: Alban 
> > ---
> > @@ -654,6 +656,25 @@ static int ath9k_init_softc(u16 devid, struct 
> > ath_softc *sc,
> > if (ret)
> > return ret;
> >  
> > +   /* If the EEPROM hasn't been retrieved via firmware request
> > +* use the nvmem API insted.
> > +*/
> > +   if (!ah->eeprom_blob) {
> > +   struct nvmem_cell *eeprom_cell;
> > +
> > +   eeprom_cell = nvmem_cell_get(ah->dev, "eeprom");
> > +   if (!IS_ERR(eeprom_cell)) {
> > +   ah->eeprom_data = nvmem_cell_read(
> > +   eeprom_cell, >eeprom_size);
> > +   nvmem_cell_put(eeprom_cell);
> > +
> > +   if (IS_ERR(ah->eeprom_data)) {
> > +   dev_err(ah->dev, "failed to read eeprom");
> > +   return PTR_ERR(ah->eeprom_data);
> > +   }
> > +   }
> > +   }
> > +
> > if (ath9k_led_active_high != -1)
> > ah->config.led_active_high = ath9k_led_active_high == 1;
> >
> Are you sure this works with AR93XX SoCs that have the calibration data
> in the OTP?

I only tested this on an ar9132 platform, so it might well be that a
few things are missing for the newer SoC. However this shouldn't break
anything existing as a platform needs to define an nvmem cell on the
athk9 device for this code to be used at all.

Alban


pgpHO7lMTUc8l.pgp
Description: OpenPGP digital signature

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

2017-03-23 Thread Alban 
On Tue, 14 Mar 2017 00:53:55 +0100
Christian Lamparter  wrote:

> On Monday, March 13, 2017 10:05:11 PM CET Alban wrote:
> > Currently SoC platforms use a firmware request to get the EEPROM data.
> > This is mostly a hack and rely on using a user-helper scripts which is
> > deprecated. A nicer alternative is to use the nvmem API which was
> > designed for this kind of task.
> > 
> > Furthermore we let CONFIG_ATH9K_AHB select CONFIG_NVMEM as such
> > devices will generally use this method for loading the EEPROM data.
> > 
> > Signed-off-by: Alban 
> > ---
> > @@ -654,6 +656,25 @@ static int ath9k_init_softc(u16 devid, struct 
> > ath_softc *sc,
> > if (ret)
> > return ret;
> >  
> > +   /* If the EEPROM hasn't been retrieved via firmware request
> > +* use the nvmem API insted.
> > +*/
> > +   if (!ah->eeprom_blob) {
> > +   struct nvmem_cell *eeprom_cell;
> > +
> > +   eeprom_cell = nvmem_cell_get(ah->dev, "eeprom");
> > +   if (!IS_ERR(eeprom_cell)) {
> > +   ah->eeprom_data = nvmem_cell_read(
> > +   eeprom_cell, >eeprom_size);
> > +   nvmem_cell_put(eeprom_cell);
> > +
> > +   if (IS_ERR(ah->eeprom_data)) {
> > +   dev_err(ah->dev, "failed to read eeprom");
> > +   return PTR_ERR(ah->eeprom_data);
> > +   }
> > +   }
> > +   }
> > +
> > if (ath9k_led_active_high != -1)
> > ah->config.led_active_high = ath9k_led_active_high == 1;
> >
> Are you sure this works with AR93XX SoCs that have the calibration data
> in the OTP?

I only tested this on an ar9132 platform, so it might well be that a
few things are missing for the newer SoC. However this shouldn't break
anything existing as a platform needs to define an nvmem cell on the
athk9 device for this code to be used at all.

Alban


pgpHO7lMTUc8l.pgp
Description: OpenPGP digital signature

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

2017-03-13 Thread Christian Lamparter 
On Monday, March 13, 2017 10:05:11 PM CET Alban wrote:
> Currently SoC platforms use a firmware request to get the EEPROM data.
> This is mostly a hack and rely on using a user-helper scripts which is
> deprecated. A nicer alternative is to use the nvmem API which was
> designed for this kind of task.
> 
> Furthermore we let CONFIG_ATH9K_AHB select CONFIG_NVMEM as such
> devices will generally use this method for loading the EEPROM data.
> 
> Signed-off-by: Alban 
> ---
> @@ -654,6 +656,25 @@ static int ath9k_init_softc(u16 devid, struct ath_softc 
> *sc,
>   if (ret)
>   return ret;
>  
> + /* If the EEPROM hasn't been retrieved via firmware request
> +  * use the nvmem API insted.
> +  */
> + if (!ah->eeprom_blob) {
> + struct nvmem_cell *eeprom_cell;
> +
> + eeprom_cell = nvmem_cell_get(ah->dev, "eeprom");
> + if (!IS_ERR(eeprom_cell)) {
> + ah->eeprom_data = nvmem_cell_read(
> + eeprom_cell, >eeprom_size);
> + nvmem_cell_put(eeprom_cell);
> +
> + if (IS_ERR(ah->eeprom_data)) {
> + dev_err(ah->dev, "failed to read eeprom");
> + return PTR_ERR(ah->eeprom_data);
> + }
> + }
> + }
> +
>   if (ath9k_led_active_high != -1)
>   ah->config.led_active_high = ath9k_led_active_high == 1;
>  
Are you sure this works with AR93XX SoCs that have the calibration data
in the OTP?

I've added Chris to the CC, since he has a HiveAP 121 that has this
configuration, so he can test, whenever this is a problem or not.

But from what I can tell, devices with the calibration data in the
OTP would fail now. This is because the OTP is done by ath9k_hw_init()
which hasn't run yet (it's a bit further down the road in the same
function though). 

Note: the OTP doesn't store the whole caldata. Just a few parts.
A temporary "eeprom" gets constructed with the help of the 
ar9300_eep_templates in ar9003_eeprom.c's
ar9300_eeprom_restore_internal(). But from what I don't think, 
that the eeprom_blob is constructed/set by the functions in
ar9003_eeprom.

I think this will require an additional property like
qca,calibration-in-otp. What's your opinion?

Thanks,
Christian

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

2017-03-13 Thread Christian Lamparter 
On Monday, March 13, 2017 10:05:11 PM CET Alban wrote:
> Currently SoC platforms use a firmware request to get the EEPROM data.
> This is mostly a hack and rely on using a user-helper scripts which is
> deprecated. A nicer alternative is to use the nvmem API which was
> designed for this kind of task.
> 
> Furthermore we let CONFIG_ATH9K_AHB select CONFIG_NVMEM as such
> devices will generally use this method for loading the EEPROM data.
> 
> Signed-off-by: Alban 
> ---
> @@ -654,6 +656,25 @@ static int ath9k_init_softc(u16 devid, struct ath_softc 
> *sc,
>   if (ret)
>   return ret;
>  
> + /* If the EEPROM hasn't been retrieved via firmware request
> +  * use the nvmem API insted.
> +  */
> + if (!ah->eeprom_blob) {
> + struct nvmem_cell *eeprom_cell;
> +
> + eeprom_cell = nvmem_cell_get(ah->dev, "eeprom");
> + if (!IS_ERR(eeprom_cell)) {
> + ah->eeprom_data = nvmem_cell_read(
> + eeprom_cell, >eeprom_size);
> + nvmem_cell_put(eeprom_cell);
> +
> + if (IS_ERR(ah->eeprom_data)) {
> + dev_err(ah->dev, "failed to read eeprom");
> + return PTR_ERR(ah->eeprom_data);
> + }
> + }
> + }
> +
>   if (ath9k_led_active_high != -1)
>   ah->config.led_active_high = ath9k_led_active_high == 1;
>  
Are you sure this works with AR93XX SoCs that have the calibration data
in the OTP?

I've added Chris to the CC, since he has a HiveAP 121 that has this
configuration, so he can test, whenever this is a problem or not.

But from what I can tell, devices with the calibration data in the
OTP would fail now. This is because the OTP is done by ath9k_hw_init()
which hasn't run yet (it's a bit further down the road in the same
function though). 

Note: the OTP doesn't store the whole caldata. Just a few parts.
A temporary "eeprom" gets constructed with the help of the 
ar9300_eep_templates in ar9003_eeprom.c's
ar9300_eeprom_restore_internal(). But from what I don't think, 
that the eeprom_blob is constructed/set by the functions in
ar9003_eeprom.

I think this will require an additional property like
qca,calibration-in-otp. What's your opinion?

Thanks,
Christian

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

2017-03-13 Thread Rafał Miłecki 

On 03/13/2017 10:05 PM, Alban wrote:

@@ -654,6 +656,25 @@ static int ath9k_init_softc(u16 devid, struct ath_softc 
*sc,
if (ret)
return ret;

+   /* If the EEPROM hasn't been retrieved via firmware request
+* use the nvmem API insted.
+*/
+   if (!ah->eeprom_blob) {
+   struct nvmem_cell *eeprom_cell;
+
+   eeprom_cell = nvmem_cell_get(ah->dev, "eeprom");
+   if (!IS_ERR(eeprom_cell)) {
+   ah->eeprom_data = nvmem_cell_read(
+   eeprom_cell, >eeprom_size);
+   nvmem_cell_put(eeprom_cell);
+
+   if (IS_ERR(ah->eeprom_data)) {
+   dev_err(ah->dev, "failed to read eeprom");


One trivial thing: missing line break.



+   return PTR_ERR(ah->eeprom_data);
+   }
+   }
+   }
+
if (ath9k_led_active_high != -1)
ah->config.led_active_high = ath9k_led_active_high == 1;

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

2017-03-13 Thread Rafał Miłecki 

On 03/13/2017 10:05 PM, Alban wrote:

@@ -654,6 +656,25 @@ static int ath9k_init_softc(u16 devid, struct ath_softc 
*sc,
if (ret)
return ret;

+   /* If the EEPROM hasn't been retrieved via firmware request
+* use the nvmem API insted.
+*/
+   if (!ah->eeprom_blob) {
+   struct nvmem_cell *eeprom_cell;
+
+   eeprom_cell = nvmem_cell_get(ah->dev, "eeprom");
+   if (!IS_ERR(eeprom_cell)) {
+   ah->eeprom_data = nvmem_cell_read(
+   eeprom_cell, >eeprom_size);
+   nvmem_cell_put(eeprom_cell);
+
+   if (IS_ERR(ah->eeprom_data)) {
+   dev_err(ah->dev, "failed to read eeprom");


One trivial thing: missing line break.



+   return PTR_ERR(ah->eeprom_data);
+   }
+   }
+   }
+
if (ath9k_led_active_high != -1)
ah->config.led_active_high = ath9k_led_active_high == 1;

[PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

2017-03-13 Thread Alban 
Currently SoC platforms use a firmware request to get the EEPROM data.
This is mostly a hack and rely on using a user-helper scripts which is
deprecated. A nicer alternative is to use the nvmem API which was
designed for this kind of task.

Furthermore we let CONFIG_ATH9K_AHB select CONFIG_NVMEM as such
devices will generally use this method for loading the EEPROM data.

Signed-off-by: Alban 
---
 drivers/net/wireless/ath/ath9k/Kconfig  |  1 +
 drivers/net/wireless/ath/ath9k/eeprom.c | 10 ++
 drivers/net/wireless/ath/ath9k/hw.h |  2 ++
 drivers/net/wireless/ath/ath9k/init.c   | 21 +
 4 files changed, 34 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/Kconfig 
b/drivers/net/wireless/ath/ath9k/Kconfig
index 783a38f..1558c03 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -49,6 +49,7 @@ config ATH9K_PCI
 config ATH9K_AHB
bool "Atheros ath9k AHB bus support"
depends on ATH9K
+   select NVMEM
default n
---help---
  This option enables the AHB bus support in ath9k.
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.c 
b/drivers/net/wireless/ath/ath9k/eeprom.c
index fb80ec8..1f28222 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom.c
@@ -127,6 +127,14 @@ static bool ath9k_hw_nvram_read_pdata(struct 
ath9k_platform_data *pdata,
 offset, data);
 }
 
+static bool ath9k_hw_nvram_read_data(struct ath_hw *ah,
+off_t offset, u16 *data)
+{
+   return ath9k_hw_nvram_read_array(ah->eeprom_data,
+ah->eeprom_size / 2,
+offset, data);
+}
+
 static bool ath9k_hw_nvram_read_firmware(const struct firmware *eeprom_blob,
 off_t offset, u16 *data)
 {
@@ -143,6 +151,8 @@ bool ath9k_hw_nvram_read(struct ath_hw *ah, u32 off, u16 
*data)
 
if (ah->eeprom_blob)
ret = ath9k_hw_nvram_read_firmware(ah->eeprom_blob, off, data);
+   else if (ah->eeprom_data)
+   ret = ath9k_hw_nvram_read_data(ah, off, data);
else if (pdata && !pdata->use_eeprom && pdata->eeprom_data)
ret = ath9k_hw_nvram_read_pdata(pdata, off, data);
else
diff --git a/drivers/net/wireless/ath/ath9k/hw.h 
b/drivers/net/wireless/ath/ath9k/hw.h
index 9cbca12..7f17c2a 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -970,6 +970,8 @@ struct ath_hw {
bool disable_5ghz;
 
const struct firmware *eeprom_blob;
+   void *eeprom_data;
+   size_t eeprom_size;
 
struct ath_dynack dynack;
 
diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index fa4b3cc..054f254 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -511,6 +512,7 @@ static int ath9k_eeprom_request(struct ath_softc *sc, const 
char *name)
 static void ath9k_eeprom_release(struct ath_softc *sc)
 {
release_firmware(sc->sc_ah->eeprom_blob);
+   kfree(sc->sc_ah->eeprom_data);
 }
 
 static int ath9k_init_platform(struct ath_softc *sc)
@@ -654,6 +656,25 @@ static int ath9k_init_softc(u16 devid, struct ath_softc 
*sc,
if (ret)
return ret;
 
+   /* If the EEPROM hasn't been retrieved via firmware request
+* use the nvmem API insted.
+*/
+   if (!ah->eeprom_blob) {
+   struct nvmem_cell *eeprom_cell;
+
+   eeprom_cell = nvmem_cell_get(ah->dev, "eeprom");
+   if (!IS_ERR(eeprom_cell)) {
+   ah->eeprom_data = nvmem_cell_read(
+   eeprom_cell, >eeprom_size);
+   nvmem_cell_put(eeprom_cell);
+
+   if (IS_ERR(ah->eeprom_data)) {
+   dev_err(ah->dev, "failed to read eeprom");
+   return PTR_ERR(ah->eeprom_data);
+   }
+   }
+   }
+
if (ath9k_led_active_high != -1)
ah->config.led_active_high = ath9k_led_active_high == 1;
 
-- 
2.7.4

[PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

2017-03-13 Thread Alban 
Currently SoC platforms use a firmware request to get the EEPROM data.
This is mostly a hack and rely on using a user-helper scripts which is
deprecated. A nicer alternative is to use the nvmem API which was
designed for this kind of task.

Furthermore we let CONFIG_ATH9K_AHB select CONFIG_NVMEM as such
devices will generally use this method for loading the EEPROM data.

Signed-off-by: Alban 
---
 drivers/net/wireless/ath/ath9k/Kconfig  |  1 +
 drivers/net/wireless/ath/ath9k/eeprom.c | 10 ++
 drivers/net/wireless/ath/ath9k/hw.h |  2 ++
 drivers/net/wireless/ath/ath9k/init.c   | 21 +
 4 files changed, 34 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/Kconfig 
b/drivers/net/wireless/ath/ath9k/Kconfig
index 783a38f..1558c03 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -49,6 +49,7 @@ config ATH9K_PCI
 config ATH9K_AHB
bool "Atheros ath9k AHB bus support"
depends on ATH9K
+   select NVMEM
default n
---help---
  This option enables the AHB bus support in ath9k.
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.c 
b/drivers/net/wireless/ath/ath9k/eeprom.c
index fb80ec8..1f28222 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom.c
@@ -127,6 +127,14 @@ static bool ath9k_hw_nvram_read_pdata(struct 
ath9k_platform_data *pdata,
 offset, data);
 }
 
+static bool ath9k_hw_nvram_read_data(struct ath_hw *ah,
+off_t offset, u16 *data)
+{
+   return ath9k_hw_nvram_read_array(ah->eeprom_data,
+ah->eeprom_size / 2,
+offset, data);
+}
+
 static bool ath9k_hw_nvram_read_firmware(const struct firmware *eeprom_blob,
 off_t offset, u16 *data)
 {
@@ -143,6 +151,8 @@ bool ath9k_hw_nvram_read(struct ath_hw *ah, u32 off, u16 
*data)
 
if (ah->eeprom_blob)
ret = ath9k_hw_nvram_read_firmware(ah->eeprom_blob, off, data);
+   else if (ah->eeprom_data)
+   ret = ath9k_hw_nvram_read_data(ah, off, data);
else if (pdata && !pdata->use_eeprom && pdata->eeprom_data)
ret = ath9k_hw_nvram_read_pdata(pdata, off, data);
else
diff --git a/drivers/net/wireless/ath/ath9k/hw.h 
b/drivers/net/wireless/ath/ath9k/hw.h
index 9cbca12..7f17c2a 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -970,6 +970,8 @@ struct ath_hw {
bool disable_5ghz;
 
const struct firmware *eeprom_blob;
+   void *eeprom_data;
+   size_t eeprom_size;
 
struct ath_dynack dynack;
 
diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index fa4b3cc..054f254 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -511,6 +512,7 @@ static int ath9k_eeprom_request(struct ath_softc *sc, const 
char *name)
 static void ath9k_eeprom_release(struct ath_softc *sc)
 {
release_firmware(sc->sc_ah->eeprom_blob);
+   kfree(sc->sc_ah->eeprom_data);
 }
 
 static int ath9k_init_platform(struct ath_softc *sc)
@@ -654,6 +656,25 @@ static int ath9k_init_softc(u16 devid, struct ath_softc 
*sc,
if (ret)
return ret;
 
+   /* If the EEPROM hasn't been retrieved via firmware request
+* use the nvmem API insted.
+*/
+   if (!ah->eeprom_blob) {
+   struct nvmem_cell *eeprom_cell;
+
+   eeprom_cell = nvmem_cell_get(ah->dev, "eeprom");
+   if (!IS_ERR(eeprom_cell)) {
+   ah->eeprom_data = nvmem_cell_read(
+   eeprom_cell, >eeprom_size);
+   nvmem_cell_put(eeprom_cell);
+
+   if (IS_ERR(ah->eeprom_data)) {
+   dev_err(ah->dev, "failed to read eeprom");
+   return PTR_ERR(ah->eeprom_data);
+   }
+   }
+   }
+
if (ath9k_led_active_high != -1)
ah->config.led_active_high = ath9k_led_active_high == 1;
 
-- 
2.7.4