Re: AP6335 with mainline kernel

[Fabio Estevam]

Hi Arend,

On Wed, Nov 28, 2018 at 6:13 PM Arend van Spriel
 wrote:

> Nice. Regarding your question in the earlier email, bit 27 in
> boardflags3 forces the device to always select external LPO signal. When
> the bit is not set it will select either internal or external. I don't
> know what the criteria for that selection are.

Thanks for your explanation and for the excellent hint on the lack of
32kHz support in the device tree.

Really appreciate it!

To close this thread, here is the dts patch that allows Wifi to work
om the imx7d-pico-pi board:
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/616048.html

Thanks,

Fabio Estevam

Re: AP6335 with mainline kernel

[Fabio Estevam]

Hi Arend,

On Wed, Nov 28, 2018 at 2:23 PM Fabio Estevam  wrote:

> I am not sure if I can access this signal via scope.

Good news!

I managed to make mx7d to generate the 32kHz clock and now Wifi works
with the default nvram file value: boardflags3 0x08101188

Thanks a lot for your help!

Re: AP6335 with mainline kernel

[Fabio Estevam]

Hi Arend,

On Wed, Nov 28, 2018 at 2:11 PM Arend Van Spriel
 wrote:

> Does it mean there is a regression in 4.20 for this board?

I haven't tested it with 4.20 yet.

>> Only change I needed was the one suggested by Arend in the nvram file:
>> changed boardflags3 entry.from 0x08101188 to 0x101188.
>
>
> Yes. That is understood. However, an external LPO clock may be more reliable 
> than using the internal, which is consequence of changing boardflags3.

Just to make sure I understand the change:

boardflags3 0x08101188 --> Wifi uses an external clock
boardflags3 0x101188 ---> Wifi uses an internal clock

Current dts does not output the 32kHz from MX7D to the Wifi chip, so I
guess the below is correct.

> So can the signal be measured with a scope to confirm it provides 32kHz?

I am not sure if I can access this signal via scope.

Thanks

Re: AP6335 with mainline kernel

[Fabio Estevam]

Hi Cameron,

On Sat, Nov 17, 2018 at 5:10 PM Fabio Estevam  wrote:

> Could you please test the following patch against mainline that
> implements this suggestion?
> http://dark-code.bulix.org/4m18pb-507579

I finally managed to get Wifi working on the imx7d-pico-pi board using
mainline 4.19.2 without any dts change.

Only change I needed was the one suggested by Arend in the nvram file:
changed boardflags3 entry.from 0x08101188 to 0x101188.

With this change I get:

# iwconfig wlan0 essid ACCESSPOINT
# wpa_passphrase ACCESSPOINT > /etc/wpa.conf
*
# wpa_supplicant -Dwext -iwlan0 -c /etc/wpa.conf &
# Successfully initialized wpa_supplicant
[   59.091981] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   59.310095] brcmfmac: brcmf_run_escan: error (-52)
[   59.314949] brcmfmac: brcmf_cfg80211_scan: scan error (-52)
ioctl[SIOCSIWSCAN]: Invalid exchange
wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
[   60.327177] brcmfmac: brcmf_run_escan: error (-52)
[   60.332152] brcmfmac: brcmf_cfg80211_scan: scan error (-52)
ioctl[SIOCSIWSCAN]: Invalid exchange
wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
[   61.344358] brcmfmac: brcmf_run_escan: error (-52)
[   61.349198] brcmfmac: brcmf_cfg80211_scan: scan error (-52)
ioctl[SIOCSIWSCAN]: Invalid exchange
wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
wlan0: Trying to associate with 94:2c:b3:31:dc:xx (SSID='ACCESSPOINT'
freq=2462 MHz)
wlan0: Associated with 94:2c:b3:31:dc:xx
wlan0: [   65.266683] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
WPA: Key negotiation completed with 94:2c:b3:31:dc:xx [PTK=CCMP GTK=TKIP]
wlan0: CTRL-EVENT-CONNECTED - Connection to 94:2c:b3:31:dc:xx
completed [id=0 id_str=]

# udhcpc -i wlan0
udhcpc: started, v1.29.3
[   73.015896] random: mktemp: uninitialized urandom read (6 bytes read)
udhcpc: sending discover
udhcpc: sending select for 192.168.0.14
udhcpc: lease of 192.168.0.14 obtained, lease time 3600
[   74.354463] brcmfmac: brcmf_inetaddr_changed: fail to get arp ip
table err:-52
deleting routers
[   74.390701] random: mktemp: uninitialized urandom read (6 bytes read)
adding dns 201.82.0.66
adding dns 201.82.0.61
adding dns 201.6.4.116
#
# ping google.com
PING google.com (216.58.202.174): 56 data bytes
64 bytes from 216.58.202.174: seq=0 ttl=50 time=26.328 ms
64 bytes from 216.58.202.174: seq=1 ttl=50 time=22.751 ms
64 bytes from 216.58.202.174: seq=2 ttl=50 time=48.735 ms
64 bytes from 216.58.202.174: seq=3 ttl=50 time=58.955 ms

If I change the dts as per my last patch the Wifi does not work.

Regards,

Fabio Estevam

Re: AP6335 with mainline kernel

[Fabio Estevam]

Hi Cameron,

On Fri, Nov 16, 2018 at 5:59 PM Cameron Kellough
 wrote:
>
> I did a quick review of the Technexion dts file and it looks like they setup 
> the iomux so that the clock Arend mentioned is needed actually gets muxed out 
> to GPIO1_IO03.
>
> From the technexion imx7d-pico.dtsi under the iomuxc_lpsr group:
>
> pinctrl_hog_2: hoggrp-2 {
> fsl,pins = <
> MX7D_PAD_GPIO1_IO03__CCM_CLKO2 0x7d /* wifi LPO 32K Hz 
> clock */
> MX7D_PAD_GPIO1_IO07__GPIO1_IO7 0x59 /* pmic sd_vel pin*/
> >;
> };

Could you please test the following patch against mainline that
implements this suggestion?
http://dark-code.bulix.org/4m18pb-507579

Thanks,

Fabio Estevam

Re: Build iw for 32bit ARM

[Fabio Estevam]

Hi Jakov,

On Mon, Sep 3, 2018 at 11:20 AM, Jakov Simunic
 wrote:
> Hi Steve,
> We are building with ptxdist, we have a compiler for arm 
> (arm-linux-gnueabihf-gcc), I am not a total novice in this, and have already 
> written some ptxdist rules, but haven't done it with non-autoconfizzed 
> packages, basically the problem is that if I use the default iw.make from the 
> ptxdist master branch, iw's Makefile tries to compile with the native 
> compiler and native libnl, no matter what option i supply it with, I always 
> get a x86-32 executable. When I modify the iw.make rule with the correct CC 
> (by making a custom compile step), it then fails to find the correct libnl 
> through pkg-config. The iw package is not modified at all. Could you suggest 
> how to hard code the CC (or that it gets it normally from a CC variable 
> supplied to the Makefile) or how to avoid pkg-config and supply the options 
> needed manually. I know this is a step back from multi-platform build 
> practices, but I just need it that way.

Maybe you can try to ask for help in the ptxdist mailing list.

[PATCH] ath10k: snoc: Remove owner assignment from platform_driver

[Fabio Estevam]

From: Fabio Estevam <fabio.este...@nxp.com>

Structure platform_driver does not need to set the owner field, as this
will be populated by the driver core.

Generated by scripts/coccinelle/api/platform_no_drv_owner.cocci.

Signed-off-by: Fabio Estevam <fabio.este...@nxp.com>
---
 drivers/net/wireless/ath/ath10k/snoc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/snoc.c 
b/drivers/net/wireless/ath/ath10k/snoc.c
index 47a4d2a..a3a7042 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -1385,7 +1385,6 @@ static struct platform_driver ath10k_snoc_driver = {
.remove = ath10k_snoc_remove,
.driver = {
.name   = "ath10k_snoc",
-   .owner = THIS_MODULE,
.of_match_table = ath10k_snoc_dt_match,
},
 };
-- 
2.7.4

Re: [PATCH 1/2] nfc: st21nfca: Check for devm_kzalloc() failure

[Fabio Estevam]

Hi Samuel,

Maybe this patch series got forgotten?



On Sat, Mar 24, 2018 at 10:44 AM, Fabio Estevam <feste...@gmail.com> wrote:
> From: Fabio Estevam <fabio.este...@nxp.com>
>
> devm_kzalloc() may fail, so we should better check for error and
> propagate the error in the case of allocation failure.
>
> This avoids a potential NULL pointer dereference later on.
>
> Signed-off-by: Fabio Estevam <fabio.este...@nxp.com>
> ---
>  drivers/nfc/st21nfca/se.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
> index 4bed9e84..fd967a3 100644
> --- a/drivers/nfc/st21nfca/se.c
> +++ b/drivers/nfc/st21nfca/se.c
> @@ -328,6 +328,8 @@ int st21nfca_connectivity_event_received(struct 
> nfc_hci_dev *hdev, u8 host,
>
> transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
>skb->len - 2, GFP_KERNEL);
> +   if (!transaction)
> +   return -ENOMEM;
>
> transaction->aid_len = skb->data[1];
> memcpy(transaction->aid, >data[2],
> --
> 2.7.4
>

[PATCH 2/2] nfc: st21nfca: Remove unnecessary devm_kzalloc() cast

[Fabio Estevam]

From: Fabio Estevam <fabio.este...@nxp.com>

There is no need to use cast for the returned value
from memory allocation functions, so remove the unnecessary cast.

Detected via Coccinelle script:
scripts/coccinelle/api/alloc/alloc_cast.cocci.

Signed-off-by: Fabio Estevam <fabio.este...@nxp.com>
---
 drivers/nfc/st21nfca/se.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index fd967a3..5b63549 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -326,8 +326,7 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev 
*hdev, u8 host,
skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
return -EPROTO;
 
-   transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
-  skb->len - 2, GFP_KERNEL);
+   transaction = devm_kzalloc(dev, skb->len - 2, GFP_KERNEL);
if (!transaction)
return -ENOMEM;
 
-- 
2.7.4

[PATCH 1/2] nfc: st21nfca: Check for devm_kzalloc() failure

[Fabio Estevam]

From: Fabio Estevam <fabio.este...@nxp.com>

devm_kzalloc() may fail, so we should better check for error and
propagate the error in the case of allocation failure.

This avoids a potential NULL pointer dereference later on.

Signed-off-by: Fabio Estevam <fabio.este...@nxp.com>
---
 drivers/nfc/st21nfca/se.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index 4bed9e84..fd967a3 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -328,6 +328,8 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev 
*hdev, u8 host,
 
transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
   skb->len - 2, GFP_KERNEL);
+   if (!transaction)
+   return -ENOMEM;
 
transaction->aid_len = skb->data[1];
memcpy(transaction->aid, >data[2],
-- 
2.7.4

Re: AP6335 with mainline kernel

[Fabio Estevam]

Hi Arend,

On Tue, Dec 5, 2017 at 12:58 PM, Vanessa Maegima
 wrote:

> Hi Arend,
>
> Sorry for this!
>
> I updated the folder on https://drive.google.com/drive/folders/1fosahjL
> N1KI5NKS59_aPZdHLpENPFHtK
>
> Thanks!

Any ideas, please?

Thanks

Re: brcmfmac experiment for a specific use case - tx throughput maximization for slow CPU with glomming

[Fabio Estevam]

Hi Jörg,

On Thu, Jun 1, 2017 at 3:37 AM, Jörg Krause  wrote:

> I'm experiencing low throughput with a BCM43362 wifi chip attached via
> SDIO to an i.MX28 [1,2]. After disabling some Kernel debug features I'm
> getting now a TCP throughput of 12.5 Mbps for the wifi interface, which
> is still below the throughput I get for the Cubietruck.

Does it help if you disable CONFIG_PROVE_LOCKING?

--- a/arch/arm/configs/mxs_defconfig
+++ b/arch/arm/configs/mxs_defconfig
@@ -175,7 +175,6 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_KERNEL=y
 CONFIG_LOCKUP_DETECTOR=y
 CONFIG_TIMER_STATS=y
-CONFIG_PROVE_LOCKING=y
 CONFIG_BLK_DEV_IO_TRACE=y
 CONFIG_STRICT_DEVMEM=y
 CONFIG_DEBUG_USER=y

Re: [PATCH 21/26] iwlwifi: mvm: print base HW address during init

[Fabio Estevam]

On Tue, Jun 27, 2017 at 2:06 PM, Kalle Valo  wrote:

> "crouded sniffer logs", what's that?

I think Luca meant 'crowded'.

Re: brcmfmac43430-sdio.bin in linux-firmware

[Fabio Estevam]

Hi Arend,

On Wed, Aug 24, 2016 at 4:22 PM, Arend Van Spriel
 wrote:

> I could, but this is handled by Cypress now. I have asked for firmware
> release tag so I can release it.

I see brcmfmac43430-sdio.bin in linux-firmware git tree now.

Thanks a lot for your help!

Re: brcmfmac43430-sdio.bin in linux-firmware

[Fabio Estevam]

Hi Arend,

On Wed, Aug 24, 2016 at 4:22 PM, Arend Van Spriel
 wrote:

> I could, but this is handled by Cypress now. I have asked for firmware
> release tag so I can release it.

Have you had a chance to release brcmfmac43430-sdio.bin?

Thanks!

Re: brcmfmac43430-sdio.bin in linux-firmware

[Fabio Estevam]

Hi Arend,

On Wed, Aug 24, 2016 at 4:22 PM, Arend Van Spriel
 wrote:

>> Is this something you could help?
>
> I could, but this is handled by Cypress now. I have asked for firmware
> release tag so I can release it.

Excellent, thanks for your help!

Re: brcmfmac43430-sdio.bin in linux-firmware

[Fabio Estevam]

Hi Arend,

On Sat, Aug 6, 2016 at 12:15 PM, Fabio Estevam <feste...@gmail.com> wrote:
> Hi,
>
> I managed to get Wifi working on a imx7 warp board, which has a BCM43430 
> device.
>
> I used the firmware from the RaspberryPi repository:
> https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm80211/brcm
>
> Are there any plans to make brcmfmac43430-sdio.bin available in the
> official linux-firmware repository?

Is this something you could help?

Thanks

brcmfmac43430-sdio.bin in linux-firmware

[Fabio Estevam]

Hi,

I managed to get Wifi working on a imx7 warp board, which has a BCM43430 device.

I used the firmware from the RaspberryPi repository:
https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm80211/brcm

Are there any plans to make brcmfmac43430-sdio.bin available in the
official linux-firmware repository?

Thanks,

Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: brcm4330 fails to load on newer kernels

[Fabio Estevam]

Hi Arend,

On Thu, Jul 28, 2016 at 3:37 PM, Arend van Spriel
<arend.vanspr...@broadcom.com> wrote:

> Hi Fabio,
>
> So this is another fine example of firmware API not able to deliver. I
> think in all these kernels you have the same issue. The problem is that
> the order of events upon kernel boot is not predictable. In this case
> you have rootfs being mounted and brcmfmac getting probed as the two
> competing events. When rootfs is mounted before brcmfmac is being probed
> it works, but if brcmfmac is probed before rootfs is mounted the
> firmware request will fail. So the only reliable option for built-in
> drivers requiring firmware is to built-in the firmware into the kernel
> as well.

Thanks for your explanation.

Tried building brcmfmac as module and after doing 'modprobe brcmfmac'
the firmware is correctly loaded from the rootfs in all the kernels I
tested.

Now I just need it to load brcmfmac module automatically, but this is
a a separate issue I will investigate.

Thanks a lot for your help!

Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: brcm4330 fails to load on newer kernels

[Fabio Estevam]

Hi Arend,

On Wed, Jul 27, 2016 at 5:51 PM, Arend van Spriel
<arend.vanspr...@broadcom.com> wrote:
> On 27-07-16 00:35, Fabio Estevam wrote:
>> Hi,
>>
>> On a imx6sl-warp board with a brcm4330 I get the following results
>> depending on the kernel version:
>>
>> - Kernel 4.4.15: place brcmfmac4330-sdio.bin and brcmfmac4330-sdio.txt
>> in the rootfs and the kernel is able to read them correctly. wlan0 is
>> present. All is fine.
>>
>> - Kernel 4.5.7: place brcmfmac4330-sdio.bin brcmfmac4330-sdio.txt in
>> the rootfs and the kernel fails to load them:
>>
>> brcmfmac mmc1:0001:1: Direct firmware load for
>> brcm/brcmfmac4330-sdio.bin failed with error -2
>>
>> Then I build brcmfmac4330-sdio.bin brcmfmac4330-sdio.txt into the
>> kernel and then firmware is detected and wlan0 appears.
>>
>> - Kernel 4.7: I can place the firmware and nvram file into the rootfs
>> or built-i and the following error is seen:
>>
>> brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50
>> brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50
>> brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50
>>
>> So wlan0 never appears here.
>>
>> Does anyone have any suggestions about these different behaviours?
>
> So for all kernel you have brcmfmac built-in the kernel or as a module?

In all these tests I have brcmfmac built-in the kernel.

Thanks,

Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

brcm4330 fails to load on newer kernels

[Fabio Estevam]

Hi,

On a imx6sl-warp board with a brcm4330 I get the following results
depending on the kernel version:

- Kernel 4.4.15: place brcmfmac4330-sdio.bin and brcmfmac4330-sdio.txt
in the rootfs and the kernel is able to read them correctly. wlan0 is
present. All is fine.

- Kernel 4.5.7: place brcmfmac4330-sdio.bin brcmfmac4330-sdio.txt in
the rootfs and the kernel fails to load them:

brcmfmac mmc1:0001:1: Direct firmware load for
brcm/brcmfmac4330-sdio.bin failed with error -2

Then I build brcmfmac4330-sdio.bin brcmfmac4330-sdio.txt into the
kernel and then firmware is detected and wlan0 appears.

- Kernel 4.7: I can place the firmware and nvram file into the rootfs
or built-i and the following error is seen:

brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50
brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50
brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50

So wlan0 never appears here.

Does anyone have any suggestions about these different behaviours?

Thanks,

Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BRCM4339 NVRAM file

[Fabio Estevam]

Hi,

I am trying to use brcm4339 on a imx6ul-pico board running kernel 4.7.

According to commit bed89b64bcbc7 (" brcmfmac: add firmware and nvram
file name for bcm4339") we need to provide brcmfmac4339-sdio.bin and
brcmfmac4339-sdio.txt files.

Was able to get the brcmfmac4339-sdio.bin from linux-firmware git
tree, but could not find the nvram file: brcmfmac4339-sdio.txt.

Does anyone know where brcmfmac4339-sdio.txt can be found?

Thanks,

Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] brcmfmac: of: Include "of.h" header file

[Fabio Estevam]

From: Fabio Estevam <fabio.este...@nxp.com>

Include "of.h" header file to fix the following sparse warning:

drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c:27:6: warning: symbol 
'brcmf_of_probe' was not declared. Should it be static?

Signed-off-by: Fabio Estevam <fabio.este...@nxp.com>
---
Resending to linux-wireless@vger.kernel.org

 drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
index 03f35e0..6231b36 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
@@ -23,6 +23,7 @@
 #include 
 #include "debug.h"
 #include "sdio.h"
+#include "of.h"
 
 void brcmf_of_probe(struct brcmf_sdio_dev *sdiodev)
 {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] NFC: fdp: i2c: Check for NULL prior to dereference

[Fabio Estevam]

Dan Carpenter reported the following:

"The patch a06347c04c13: "NFC: Add Intel Fields Peak NFC solution
driver" from Oct 22, 2015, leads to the following Smatch complaint:

drivers/nfc/fdp/i2c.c:216 fdp_nci_i2c_irq_thread_fn()
 warn: variable dereferenced before check 'phy' (see line 213)

drivers/nfc/fdp/i2c.c
   212
   213  client = phy->i2c_dev;
 ^
Dereference.

   214  dev_dbg(>dev, "%s\n", __func__);
   215
   216  if (!phy || irq != phy->i2c_dev->irq) {

Check.

   217  WARN_ON_ONCE(1);
   218  return IRQ_NONE;
"

Reported-by: Dan Carpenter <dan.carpen...@oracle.com>
Signed-off-by: Fabio Estevam <fabio.este...@freescale.com>
---
 drivers/nfc/fdp/i2c.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/nfc/fdp/i2c.c b/drivers/nfc/fdp/i2c.c
index 532db28..a5d7332 100644
--- a/drivers/nfc/fdp/i2c.c
+++ b/drivers/nfc/fdp/i2c.c
@@ -210,14 +210,14 @@ static irqreturn_t fdp_nci_i2c_irq_thread_fn(int irq, 
void *phy_id)
struct sk_buff *skb;
int r;
 
-   client = phy->i2c_dev;
-   dev_dbg(>dev, "%s\n", __func__);
-
if (!phy || irq != phy->i2c_dev->irq) {
WARN_ON_ONCE(1);
return IRQ_NONE;
}
 
+   client = phy->i2c_dev;
+   dev_dbg(>dev, "%s\n", __func__);
+
r = fdp_nci_i2c_read(phy, );
 
if (r == -EREMOTEIO)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html