Re: [PATCH] NFC: fdp: Fix unused variable warnings

2018-06-18 Thread Samuel Ortiz
Hi Amit,

On Tue, Jun 12, 2018 at 07:44:10PM +0530, Amit Pundir wrote:
> Fix unused variable warnings reported on next-20180612.
> 
> Fixes: 7579d009c4a1 ("NFC: fdp: Remove __func__ from dev_dbg()")
> Signed-off-by: Amit Pundir 
> ---
>  drivers/nfc/fdp/fdp.c | 13 -
>  1 file changed, 13 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH 1/2] NFC: st95hf: initialize semaphore and mutex earlier

2018-06-03 Thread Samuel Ortiz
Hi Daniel,

On Mon, May 28, 2018 at 09:39:01PM +0200, Daniel Mack wrote:
> On Monday, May 28, 2018 04:50 PM, Samuel Ortiz wrote:
> > Hi Daniel,
> > 
> > On Mon, May 28, 2018 at 04:35:15PM +0200, Daniel Mack wrote:
> > > On Wednesday, May 16, 2018 03:32 PM, Daniel Mack wrote:
> > > > 'rm_lock' and 'exchange_lock' need to be ready before the IRQ handler 
> > > > has a
> > > > chance to fire.
> > > > 
> > > > This fixes the oops below.
> > > 
> > > Nobody seems to be interested in these. Davem, can you take them through
> > > your tree or is there anyone else I can ping?
> > I'm going to gather all pending NFC patches this week, including this
> > one.
> > They will land in either the nfc-next or nfc-fixes tree.
> 
> Ah, perfect. Sorry for nagging. I just wanted to be sure they're not
> forgotten :)
Both patches applied to nfc-next now, thanks.

Cheers,
Samuel.


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

2018-06-03 Thread Samuel Ortiz
Hi Fabio,

On Mon, Apr 23, 2018 at 08:50:04AM -0300, Fabio Estevam wrote:
> Hi Samuel,
> 
> Maybe this patch series got forgotten?
Both patches applied to nfc-next, sorry for the lag.

Cheers,
Samuel.


Re: [PATCH 1/2] NFC: st95hf: initialize semaphore and mutex earlier

2018-05-28 Thread Samuel Ortiz
Hi Daniel,

On Mon, May 28, 2018 at 04:35:15PM +0200, Daniel Mack wrote:
> On Wednesday, May 16, 2018 03:32 PM, Daniel Mack wrote:
> > 'rm_lock' and 'exchange_lock' need to be ready before the IRQ handler has a
> > chance to fire.
> > 
> > This fixes the oops below.
> 
> Nobody seems to be interested in these. Davem, can you take them through
> your tree or is there anyone else I can ping?
I'm going to gather all pending NFC patches this week, including this
one.
They will land in either the nfc-next or nfc-fixes tree.

Cheers,
Samuel.



Re: [PATCH 1/2] NFC: st95hf: initialize semaphore and mutex earlier

2018-05-28 Thread Samuel Ortiz
Hi Daniel,

On Mon, May 28, 2018 at 04:35:15PM +0200, Daniel Mack wrote:
> On Wednesday, May 16, 2018 03:32 PM, Daniel Mack wrote:
> > 'rm_lock' and 'exchange_lock' need to be ready before the IRQ handler has a
> > chance to fire.
> > 
> > This fixes the oops below.
> 
> Nobody seems to be interested in these. Davem, can you take them through
> your tree or is there anyone else I can ping?
I'm going to gather all pending NFC patches this week. I'll take that
one.

Cheers,
Samuel.


[GIT] [4.15] NFC update

2017-11-10 Thread Samuel Ortiz
Hi David,

This is the NFC pull request for 4.15. We have:

- A new netlink command for explicitly deactivating NFC targets
- i2c constification for all NFC drivers
- One NFC device allocation error path fix

The following changes since commit 2798b80b385384d51a81832556ee9ad25d175f9b:

  Merge branch 'eBPF-based-device-cgroup-controller' (2017-11-05 23:26:51 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next.git 
tags/nfc-next-4.15-1

for you to fetch changes up to 4d63adfe12dd9cb61ed8badb4d798955399048c2:

  NFC: Add NFC_CMD_DEACTIVATE_TARGET support (2017-11-10 00:03:39 +0100)


Allen Pais (1):
  NFC: Convert timers to use timer_setup()

Arvind Yadav (8):
  nfc: microread: constify i2c_device_id
  nfc: nfcmrvl: constify i2c_device_id
  nfc: nxp-nci: constify i2c_device_id
  nfc: pn533: constify i2c_device_id
  nfc: pn544: constify i2c_device_id
  nfc: s3fwrn5: constify i2c_device_id
  nfc: st-nci: constify i2c_device_id
  nfc: st21nfca: constify i2c_device_id

Colin Ian King (2):
  nfc: s3fwrn5: make array match static const
  NFC: fdp: make struct nci_ops static

Johan Hovold (1):
  NFC: fix device-allocation error return

Mark Greer (2):
  NFC: digital: Abort cmd when deactivating target
  NFC: Add NFC_CMD_DEACTIVATE_TARGET support

 drivers/nfc/fdp/fdp.c  |  2 +-
 drivers/nfc/microread/i2c.c|  2 +-
 drivers/nfc/nfcmrvl/i2c.c  |  2 +-
 drivers/nfc/nxp-nci/i2c.c  |  2 +-
 drivers/nfc/pn533/i2c.c|  2 +-
 drivers/nfc/pn544/i2c.c|  2 +-
 drivers/nfc/s3fwrn5/firmware.c |  2 +-
 drivers/nfc/s3fwrn5/i2c.c  |  2 +-
 drivers/nfc/st-nci/i2c.c   |  2 +-
 drivers/nfc/st21nfca/i2c.c |  2 +-
 include/uapi/linux/nfc.h   |  2 ++
 net/nfc/core.c | 10 --
 net/nfc/digital_core.c |  1 +
 net/nfc/hci/core.c |  7 +++
 net/nfc/hci/llc_shdlc.c| 23 +--
 net/nfc/llcp_core.c| 14 ++
 net/nfc/netlink.c  | 29 +
 17 files changed, 64 insertions(+), 42 deletions(-)


Re: [PATCH 0/4] neard: Add support for deactivating tags

2017-11-09 Thread Samuel Ortiz
On Thu, Jun 15, 2017 at 08:57:24PM -0700, Mark Greer wrote:
> This series adds the ability for client apps to deactivate a currently
> active tag.  Once deactivated, the client can either poll again to
> reactivate the tag or power the adapter off to save power.  These
> changes will not work until the Linux kernel commits submitted under
> the subject, "NFC: Add deactivate target functionality" are committed.
> Those commits can be viewed here:
> 
>   https://lists.01.org/pipermail/linux-nfc/2017-June/004415.html
> 
> The commits are based on the commits submitted previously under the
> subject, "[PATCH 00/23] neard: Support TI Std & Pro tags, fixups, etc."
> which can be viewed here:
> 
>   https://lists.01.org/pipermail/linux-nfc/2017-June/004392.html
> 
> For convenience, these commits are available in the 'submit/deactivate_tag-v1'
> branch of this repo on github:
> 
>   https://github.com/animalcreek/neard.git
> 
> Mark Greer (4):
>   adapter: Make adapter_start_poll() global
>   adapter: Add call indicating whether constant poll is enabled
>   tag: Add Tag deactivate support
>   test: Add option to deactivate tag
All 4 patches applied, thanks.

Cheers,
Samuel.


Re: [PATCH 00/23] neard: Support TI Std & Pro tags, fixups, etc.

2017-11-09 Thread Samuel Ortiz
Hi Mark,

On Thu, Jun 15, 2017 at 11:24:53AM -0700, Mark Greer wrote:
> This is an assortment of commits that make some fixups, do some general
> tightening of NDEF data checking, add support for TI Standard and Pro
> Type 5 tags, and stop issuing the Read Multiple Blocks command when
> formatting a Type 5 tag.  The reasoning for each change is in the
> individual commit descriptions.
> 
> For convenience, a branch with these commits is available in the
> submit/updates-v1 branch here:
> 
>   https://github.com/animalcreek/neard.git
Applied, thanks.

Cheers,
Samuel.


Re: [PATCH 0/2] NFC: Add deactivate target functionality

2017-11-09 Thread Samuel Ortiz
Hi Mark,

On Thu, Jun 15, 2017 at 08:34:20PM -0700, Mark Greer wrote:
> There is currently no way for userspace to deactivate an active target.
> Since the target is active, the adapter cannot be powered down which
> wastes wastes power when the target has been read and isn't needed
> anymore (but remains within range).  To solve this, add a way to
> deactivate a currently active target which will then allow the adapter
> to be powered down.
> 
> To be fully operational, this requires companion patches for neard.
> Those patches will be submitted shortly.
> 
> Mark Greer (2):
>   NFC: digital: Abort cmd when deactivating target
>   NFC: Add NFC_CMD_DEACTIVATE_TARGET support
Both patches applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH] NFC: fdp: make struct nci_ops static

2017-11-05 Thread Samuel Ortiz
On Thu, Oct 05, 2017 at 10:47:12AM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The structure nci_ops is local to the source and does not need to
> be in global scope, so make it static.
> 
> Cleans up sparse warning:
> symbol 'nci_ops' was not declared. Should it be static?
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/nfc/fdp/fdp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
Applied as well, thanks.

Cheers,
Samuel.


Re: [PATCH] nfc: s3fwrn5: make array match static const, reduces object code size

2017-11-05 Thread Samuel Ortiz
Hi Colin,

On Tue, Sep 19, 2017 at 03:25:15PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Don't populate the read-only array match on the stack, instead make
> it static const.  Makes the object code smaller by over 310 bytes:
> 
> Before:
>text  data bss dec hex filename
>8304  1084 1289516252c drivers/nfc/s3fwrn5/firmware.o
> 
> After:
>text  data bss dec hex filename
>7894  1180 128920223f2 drivers/nfc/s3fwrn5/firmware.o
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/nfc/s3fwrn5/firmware.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH 0/8] constify nfc i2c_device_id

2017-11-05 Thread Samuel Ortiz
Hi Arvind,

On Mon, Aug 21, 2017 at 10:33:52PM +0530, Arvind Yadav wrote:
> i2c_device_id are not supposed to change at runtime. All functions
> working with i2c_device_id provided by  work with
> const i2c_device_id. So mark the non-const structs as const.
> 
> Arvind Yadav (8):
>   [PATCH 1/8] nfc: microread: constify i2c_device_id
>   [PATCH 2/8] nfc: nfcmrvl: constify i2c_device_id
>   [PATCH 3/8] nfc: nxp-nci: constify i2c_device_id
>   [PATCH 4/8] nfc: pn533: constify i2c_device_id
>   [PATCH 5/8] nfc: pn544: constify i2c_device_id
>   [PATCH 6/8] nfc: s3fwrn5: constify i2c_device_id
>   [PATCH 7/8] nfc: st-nci: constify i2c_device_id
>   [PATCH 8/8] nfc: st21nfca: constify i2c_device_id
All 8 patches applied, thanks.

Cheers,
Samuel.


Re: [PATCH] NFC: fix device-allocation error return

2017-11-05 Thread Samuel Ortiz
Hi Johan,

On Sun, Jul 09, 2017 at 01:08:58PM +0200, Johan Hovold wrote:
> A recent change fixing NFC device allocation itself introduced an
> error-handling bug by returning an error pointer in case device-id
> allocation failed. This is clearly broken as the callers still expected
> NULL to be returned on errors as detected by Dan's static checker.
> 
> Fix this up by returning NULL in the event that we've run out of memory
> when allocating a new device id.
> 
> Note that the offending commit is marked for stable (3.8) so this fix
> needs to be backported along with it.
> 
> Fixes: 20777bc57c34 ("NFC: fix broken device allocation")
> Cc: stable    # 3.8
> Reported-by: Dan Carpenter 
> Signed-off-by: Johan Hovold 
> ---
>  net/nfc/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks for the fix.

Cheers,
Samuel.


[GIT] [4.13] NFC update

2017-06-30 Thread Samuel Ortiz
Hi David,

This is the NFC pull request for 4.13. We have:

- A conversion to unified device and GPIO APIs for the
  fdp, pn544, and st{21,-nci} drivers.
- A fix for NFC device IDs allocation.
- A fix for the nfcmrvl driver firmware download mechanism.
- A trf7970a DT and GPIO cleanup and clock setting fix.
- A few fixes for potential overflows in the digital and LLCP code.

The following changes since commit 06d4d450db770a70b29fa0244d50390c85e7e3c7:

  net: dsa: Fix legacy probing (2017-06-17 22:59:45 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next.git 
tags/nfc-next-4.13-1

for you to fetch changes up to bd751808f9ff5e1822c627f6c4283009e66b2e53:

  NFC: trf7970a: Correct register settings for 27MHz clock (2017-06-28 09:16:54 
+0200)


Andy Shevchenko (13):
  NFC: pn544: Switch to devm_acpi_dev_add_driver_gpios()
  NFC: st21nfca: Add GPIO ACPI mapping table
  NFC: st21nfca: Get rid of code duplication in ->probe()
  NFC: fdp: Convert I2C driver to ->probe_new()
  NFC: fdp: Convert to use devres API
  NFC: fdp: Add GPIO ACPI mapping table
  NFC: st-nci: Get rid of platform data
  NFC: st-nci: Get rid of "interesting" use of interrupt polarity
  NFC: st-nci: Covert to use GPIO descriptor
  NFC: st-nci: Use unified device properties API meaningfully
  NFC: st-nci: Add GPIO ACPI mapping table
  NFC: st-nci: Get rid of code duplication in ->probe()
  MAINTAINERS: Remove non-existing NFC platform data files

Colin Ian King (1):
  NFC: trf7970a: fix check of clock frequencies, use && instead of ||

Geoff Lansberry (1):
  NFC: trf7970a: Correct register settings for 27MHz clock

Gustavo A. R. Silva (2):
  nfc: nci: remove unnecessary null check
  NFC: add NULL checks to avoid potential NULL pointer dereference

Johan Hovold (8):
  NFC: fix broken device allocation
  NFC: nfcmrvl_uart: add missing tty-device sanity check
  NFC: nfcmrvl: do not use device-managed resources
  NFC: nfcmrvl: use nfc-device for firmware download
  NFC: nfcmrvl: fix firmware-management initialisation
  NFC: nfcmrvl_uart: fix device-node leak during probe
  NFC: nfcmrvl_usb: use interface as phy device
  NFC: nfcmrvl: allow gpio 0 for reset signalling

Mark Greer (12):
  MAINTAINERS: NFC: trf7970a: Add Mark Greer as maintainer
  NFC: trf7970a: Don't de-assert EN2 unless it was asserted
  NFC: trf7970a: Fix inaccurate comment in trf7970a_probe()
  NFC: trf7970a: Only check 'en2-rf-quirk' if EN2 is specified
  NFC: trf7970a: Remove useless comment
  NFC: trf7970a: Remove support for 'vin-voltage-override' DT property
  NFC: trf7970a: Enable pins are active high not active low
  NFC: trf7970a: Convert to descriptor based GPIO interface
  NFC: trf7970a: Clean up coding style issues
  NFC: digital: NFC-A SEL_RES must be one byte
  NFC: digital: NFC-DEP Target WT(nfcdep,max) is now 14
  Revert "NFC: trf7970a: Handle extra byte in response to Type 5 RMB 
commands"

Markus Elfring (2):
  NFC: digital: Improve a size determination in four functions
  NFC: digital: Delete an error message for memory allocation failure

Mateusz Jurczyk (3):
  nfc: Fix the sockaddr length sanitization in llcp_sock_connect
  nfc: Ensure presence of required attributes in the activate_target handler
  NFC: Add sockaddr length checks before accessing sa_family in bind 
handlers

 .../devicetree/bindings/net/nfc/trf7970a.txt   |  10 +-
 MAINTAINERS|  11 +-
 drivers/nfc/Kconfig|   2 +-
 drivers/nfc/fdp/fdp.c  |  15 +-
 drivers/nfc/fdp/i2c.c  |  38 +-
 drivers/nfc/nfcmrvl/fw_dnld.c  |   7 +-
 drivers/nfc/nfcmrvl/main.c |  40 ++-
 drivers/nfc/nfcmrvl/uart.c |  11 +-
 drivers/nfc/nfcmrvl/usb.c  |   4 +-
 drivers/nfc/nfcsim.c   |   6 +-
 drivers/nfc/pn544/i2c.c|   3 +-
 drivers/nfc/st-nci/i2c.c   | 164 ++---
 drivers/nfc/st-nci/spi.c   | 162 ++---
 drivers/nfc/st21nfca/i2c.c |  62 +---
 drivers/nfc/trf7970a.c | 391 ++---
 include/linux/platform_data/nfcmrvl.h  |   2 +-
 include/linux/platform_data/st-nci.h   |  31 --
 net/nfc/core.c |  31 +-
 net/nfc/digital_core.c |  12 +-
 net/nfc/digital_dep.c  |   2 +-
 net/nfc/digital_technology.c   |   3 +-
 net/nfc/llcp_sock.c|   9 +-
 net/nfc/nci/core.c  

Re: [PATCH v4] NFC: trf7970a: Correct register settings for 27MHz clock

2017-06-28 Thread Samuel Ortiz
Hi Geoff,

On Thu, Apr 27, 2017 at 05:28:46PM -0400, Geoff Lansberry wrote:
> In prior commits the selected clock frequency does not propagate
> correctly to what is written to the TRF7970A_MODULATOR_SYS_CLK_CTRL
> register.
> 
> Signed-off-by: Geoff Lansberry 
> ---
>  drivers/nfc/trf7970a.c | 7 +++
>  1 file changed, 7 insertions(+)
Applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [[linux-nfc][PATCH v1] 2/6] NFC: nfcst: Add ST NFC Transceiver core framework

2017-06-25 Thread Samuel Ortiz
Hi Shikha,

On Tue, May 02, 2017 at 02:03:39AM -0400, Shikha Singh wrote:
> +static int nfcst_in_send_cmd(struct nfc_digital_dev *ddev,
> +  struct sk_buff *skb,
> +  u16 timeout,
> +  nfc_digital_cmd_complete_t cb,
> +  void *arg)
> +{
> + struct nfcst_context *context = nfc_digital_get_drvdata(ddev);
> + int rc;
> + int len_data_to_tag = 0;
> +
> + if (!context->nfcst_power)
> + return -EIO;
> +
> + /*
> +  * down the semaphore to indicate that last nfcst_in_send_cmd()
> +  * call is pending, If interrupted, WARN and return !
> +  */
> + rc = down_killable(>exchange_lock);
> + if (rc) {
> + WARN(1, "Semaphore wait is interrupted in nfcst_in_send_cmd\n");
> + return rc;
> + }
> +
> + if (context->trig_config) {
> + context->trig_config = false;
> + rc = nfcst_handle_config_fdt(context, false);
> + if (rc) {
> + dev_err(>nfcdev->dev, "config fdt failed from 
> nfcst_in_send_cmd %d\n",
> + rc);
> + return rc;
> + }
> + }
> +
> + switch (context->current_rf_tech) {
> + case NFC_DIGITAL_RF_TECH_106A:
> + len_data_to_tag = skb->len + 1;
> + *skb_put(skb, 1) = context->sendrcv_trflag;
You can't dereference a void pointer. Please fix that as it will most
likely break the build.

Cheers,
Samuel.


Re: [PATCH] NFC: nci: Remove an unneeded NULL check

2017-06-22 Thread Samuel Ortiz
Hi Dan,

On Wed, Jun 14, 2017 at 10:49:46AM +0300, Dan Carpenter wrote:
> "conn_info" can't be NULL here.  Also we just dereferenced it a couple
> lines earlier, so that makes static checkers complain.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
> index 61fff422424f..5542fc72f020 100644
> --- a/net/nfc/nci/core.c
> +++ b/net/nfc/nci/core.c
> @@ -73,11 +73,9 @@ int nci_get_conn_info_by_dest_type_params(struct nci_dev 
> *ndev, u8 dest_type,
>   if (conn_info->dest_type == dest_type) {
>   if (!params)
>   return conn_info->conn_id;
> - if (conn_info) {
> - if (params->id == conn_info->dest_params->id &&
> - params->protocol == 
> conn_info->dest_params->protocol)
> - return conn_info->conn_id;
> - }
> + if (params->id == conn_info->dest_params->id &&
> + params->protocol == 
> conn_info->dest_params->protocol)
> + return conn_info->conn_id;
A similar patch was sent earlier and is now applied:
https://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next.git/commit/?id=03036184e9d4a5b2b42a70b66db9455808dd5da9

Cheers,
Samuel.



Re: [PATCH] nfc: Add sockaddr length checks before accessing sa_family in bind handlers

2017-06-22 Thread Samuel Ortiz
On Tue, Jun 13, 2017 at 06:44:28PM +0200, Mateusz Jurczyk wrote:
> Verify that the caller-provided sockaddr structure is large enough to
> contain the sa_family field, before accessing it in bind() handlers of the
> AF_NFC socket. Since the syscall doesn't enforce a minimum size of the
> corresponding memory region, very short sockaddrs (zero or one byte long)
> result in operating on uninitialized memory while referencing .sa_family.
> 
> Signed-off-by: Mateusz Jurczyk 
> ---
>  net/nfc/llcp_sock.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH] NFC: add NULL checks to avoid potential NULL pointer dereference

2017-06-22 Thread Samuel Ortiz
On Tue, May 30, 2017 at 03:43:07PM -0500, Gustavo A. R. Silva wrote:
> NULL checks at line 457: if (!link0 || !link1) {, implies that both
> pointers link0 and link1 might be NULL.
> Function nfcsim_link_free() dereference pointers link0 and link1.
> Add NULL checks before calling nfcsim_link_free() to avoid a
> potential NULL pointer dereference.
> 
> Addresses-Coverity-ID: 1364857
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/nfc/nfcsim.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
Applied, thanks.

Cheers,
Samuel.


Re: [PATCH] nfc: nci: remove unnecessary null check

2017-06-22 Thread Samuel Ortiz
Hi Gustavo,

On Tue, Jun 13, 2017 at 11:37:18AM -0500, Gustavo A. R. Silva wrote:
> Remove unnecessary NULL check for pointer conn_info.
> conn_info is set in list_for_each_entry() using container_of(),
> which is never NULL.
> 
> Addresses-Coverity-ID: 1362349
> Cc: Guenter Roeck 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  net/nfc/nci/core.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH] nfc: Ensure presence of required attributes in the activate_target netlink handler

2017-06-22 Thread Samuel Ortiz
Hi Mateusz,

On Wed, May 24, 2017 at 12:42:26PM +0200, Mateusz Jurczyk wrote:
> Check that the NFC_ATTR_TARGET_INDEX and NFC_ATTR_PROTOCOLS attributes (in
> addition to NFC_ATTR_DEVICE_INDEX) are provided by the netlink client
> prior to accessing them. This prevents potential unhandled NULL pointer
> dereference exceptions which can be triggered by malicious user-mode
> programs, if they omit one or both of these attributes.
> 
> Signed-off-by: Mateusz Jurczyk 
> ---
>  net/nfc/netlink.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
Applied, thanks.

Cheers,
Samuel.


Re: [PATCH] nfc: Fix the sockaddr length sanitization in llcp_sock_connect

2017-06-22 Thread Samuel Ortiz
Hi Mateusz,

On Wed, May 24, 2017 at 12:26:20PM +0200, Mateusz Jurczyk wrote:
> Fix the sockaddr length verification in the connect() handler of NFC/LLCP
> sockets, to compare against the size of the actual structure expected on
> input (sockaddr_nfc_llcp) instead of its shorter version (sockaddr_nfc).
> 
> Both structures are defined in include/uapi/linux/nfc.h. The fields
> specific to the _llcp extended struct are as follows:
> 
>276__u8 dsap; /* Destination SAP, if known */
>277__u8 ssap; /* Source SAP to be bound to */
>278char service_name[NFC_LLCP_MAX_SERVICE_NAME]; /* 
> Service name URI */;
>279size_t service_name_len;
> 
> If the caller doesn't provide a sufficiently long sockaddr buffer, these
> fields remain uninitialized (and they currently originate from the stack
> frame of the top-level sys_connect handler). They are then copied by
> llcp_sock_connect() into internal storage (nfc_llcp_sock structure), and
> could be subsequently read back through the user-mode getsockname()
> function (handled by llcp_sock_getname()). This would result in the
> disclosure of up to ~70 uninitialized bytes from the kernel stack to
> user-mode clients capable of creating AFC_NFC sockets.
> 
> Signed-off-by: Mateusz Jurczyk 
> ---
>  net/nfc/llcp_sock.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH 0/3] NFC: Misc. kernel updates and trf7970a erratum handling

2017-06-22 Thread Samuel Ortiz
Hi Mark,

On Thu, Jun 15, 2017 at 10:46:14AM -0700, Mark Greer wrote:
> Add a couple minor fixups and remove the trf7970a erratum handling
> in which the last byte in the response to a Type 5 Read Multiple Blocks
> command is discarded.  That handling is moved to the neard daemon where
> there is enough context to do it properly.
> 
> Mark Greer (3):
>   NFC: digital: NFC-A SEL_RES must be one byte
>   NFC: digital: NFC-DEP Target WT(nfcdep,max) is now 14
>   Revert "NFC: trf7970a: Handle extra byte in response to Type 5 RMB
> commands"
All 3 patches applied, thanks.

Cheers,
Samuel.


Re: [PATCH 0/2] NFC-digital: Adjustments for four function implementations

2017-06-22 Thread Samuel Ortiz
Hi Markus,

On Mon, May 22, 2017 at 02:57:42PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Mon, 22 May 2017 14:50:05 +0200
> 
> Two update suggestions were taken into account
> from static source code analysis.
> 
> Markus Elfring (2):
>   Improve a size determination in four functions
>   Delete an error message for a failed memory allocation in digital_in_send()
Both patches applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH] NFC: trf7970a: fix check of clock frequencies, use && instead of ||

2017-06-22 Thread Samuel Ortiz
Hi Colin,

On Mon, Apr 24, 2017 at 02:36:02PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The "or" condition (clk_freq != TRF7970A_27MHZ_CLOCK_FREQUENCY) ||
> (clk_freq != TRF7970A_13MHZ_CLOCK_FREQUE) will always be true because
> clk_freq cannot be equal to two different values at the same time. Use
> the  && operator instead of || to fix this.
> 
> Detected by CoverityScan, CID#1430468 ("Constant expression result")
> 
> Fixes: 837eb4d21ecde7 ("NFC: trf7970a: add device tree option for 27MHz 
> clock")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/nfc/trf7970a.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH v3 00/13] NFC: clean up for ACPI GPIO usage

2017-06-22 Thread Samuel Ortiz
Hi Andy,

On Mon, Jun 19, 2017 at 01:08:45PM +0300, Andy Shevchenko wrote:
> This clean up series to NFC drivers that are using GPIOs on ACPI enabled
> platforms. Since GPIO ACPI library goes stricter about requesting
> resources we need to amend drivers for that. Here we are for NFC
> subsystem.
> 
> While doing above, get rid of legacy and unused platform data as well as
> some artificial IDs.
> 
> Changelog v3:
> - incorporate Samuel's fixes
> - fix the bug kbuild bot complains about
> - add MAINTAINERS patch
> 
> Changelog v2:
> - add patches 1,4-12
> 
> Andy Shevchenko (13):
>   NFC: pn544: Switch to devm_acpi_dev_add_driver_gpios()
>   NFC: st21nfca: Add GPIO ACPI mapping table
>   NFC: st21nfca: Get rid of code duplication in ->probe()
>   NFC: fdp: Convert I2C driver to ->probe_new()
>   NFC: fdp: Convert to use devres API
>   NFC: fdp: Add GPIO ACPI mapping table
>   NFC: st-nci: Get rid of platform data
>   NFC: st-nci: Get rid of "interesting" use of interrupt polarity
>   NFC: st-nci: Covert to use GPIO descriptor
>   NFC: st-nci: Use unified device properties API meaningfully
>   NFC: st-nci: Add GPIO ACPI mapping table
>   NFC: st-nci: Get rid of code duplication in ->probe()
>   MAINTAINERS: Remove non-existing NFC platform data files
All patches applied, thanks.

Cheers,
Samuel.


Re: [PATCH v2 00/12] NFC: clean up for ACPI GPIO usage

2017-06-18 Thread Samuel Ortiz
Hi Andy,

On Mon, Jun 05, 2017 at 11:19:57PM +0300, Andy Shevchenko wrote:
> Andy Shevchenko (12):
>   NFC: pn544: Switch to devm_acpi_dev_add_driver_gpios()
>   NFC: st21nfca: Add GPIO ACPI mapping table
>   NFC: st21nfca: Get rid of code duplication in ->probe()
>   NFC: fdp: Convert I2C driver to ->probe_new()
>   NFC: fdp: Convert to use devres API
>   NFC: fdp: Add GPIO ACPI mapping table
>   NFC: st-nci: Get rid of platform data
>   NFC: st-nci: Get rid of "interesting" use of interrupt polarity
>   NFC: st-nci: Covert to use GPIO descriptor
>   NFC: st-nci: Use unified device property API meaningfully
>   NFC: st-nci: Add GPIO ACPI mapping table
>   NFC: st-nci: Get rid of code duplication in ->probe()
After fixing a couple of nitpicks, all patches applied now.
I'm fine with getting rid of the platform data, let's see if out of tree
users (especially for the ST driver) complain. Also, I'd appreciate if
you could cc linux-nfc to your submissions.

Cheers,
Samuel.


Re: [PATCH v2 00/12] NFC: clean up for ACPI GPIO usage

2017-06-12 Thread Samuel Ortiz
Andy,

On Mon, Jun 12, 2017 at 06:36:12PM +0300, Andy Shevchenko wrote:
> On Mon, 2017-06-05 at 23:19 +0300, Andy Shevchenko wrote:
> > This clean up series to NFC drivers that are using GPIOs on ACPI
> > enabled
> > platforms. Since GPIO ACPI library goes stricter about requesting
> > resources we need to amend drivers for that. Here we are for NFC
> > subsystem.
> > 
> > While doing above, get rid of legacy and unused platform data as well
> > as
> > some artificial IDs.
> 
> Samuel, anything to comment?
I will get to my pending NFC patches during the week.

Cheers,
Samuel.


Re: [[linux-nfc] PATCH v1.0 0/6] Support for ST NFC Transceiver

2017-04-28 Thread Samuel Ortiz
Hi Shikha,

That one is next on my review list.
Could you please rebase it on top of nfc-next though ?

Cheers,
Samuel.

On Fri, Apr 28, 2017 at 04:31:16AM +, Shikha SINGH wrote:
> Hello Samuel,
>Could you please consider the below patch series for integration in 
> Linux-NFC mainline?
> A long time ago we released this patch series but did not get any review 
> comments or update.
> 
> This release is important for our customers who always prefer to pick the 
> release from mainline.
>  
> Thanks for your comments.
> 
> Thanks & Regards,
> Shikha
> 
> >>-Original Message-
> >>From: Shikha SINGH
> >>Sent: Friday, July 22, 2016 9:56 AM
> >>To: sa...@linux.intel.com; linux-...@lists.01.org
> >>Cc: Raunaque Mujeeb QUAISER ; Manoj
> >KUMAR
> >>; Sylvain FIDELIS ; Patrick
> >>SOHN ; Shikha SINGH ;
> >Raphael
> >>COLLADO 
> >>Subject: [[linux-nfc] PATCH v1.0 0/6] Support for ST NFC Transceiver
> >>
> >>*** STMicrolectronics NFC v1.0 ***
> >>This patch series introduces the following features:
> >>
> >>(a) A generic Digital NFC UART framework.
> >>The framework itself is an LDISC registered with the tty core. Any NFC
> >>transciever implementing the digital specs and connected on an UART (or
> >>on an emulated tty, such as /dev/ttyUSBx, /dev/ttyACMx) interface with
> >>the host, will require this support.
> >>
> >>(b) An ST NFC Transciever core framework. This implements the required
> >>digital ops and exposes an interface for the underlying phy drivers
> >>(UART/ SPI). The services of the phy drivers are required when the core
> >>wants to transmit/receive frames.
> >>Also it provides helper functions for the phy drivers, for example phy
> >>drivers registers with the core when it detects a Transciever connected
> >>on the corresponding interface.
> >>The framework currently supports NFC Type 2, Type 4A, Type 4B, Type 5
> >>tag read/write.
> >>
> >>(c) An ST NFC UART LDisc driver that registers with the Digital NFC
> >>UART framework, and with the ST NFC Transciever core framework as the
> >>UART Phy driver.
> >>
> >>(d) An ST NFC SPI driver that register with ST NFC Transceiver core
> >>framework as SPI phy driver.
> >>
> >>(e) This patch series also removes all the references of old ST NFC
> >>transceiver driver "st95hf".
> >>
> >>Shikha Singh (6):
> >>  NFC: add generic UART support
> >>  NFC: nfcst: Add ST NFC Transceiver core framework
> >>  NFC: nfctst: Add UART LDisc Driver
> >>  NFC: nfctst: Add ST NFC SPI Driver
> >>  DT: bindings: net: nfc: stnfc binding doc
> >>  DRIVERS: NFC: Remove st95hf
> >>
> >> .../devicetree/bindings/net/nfc/st95hf.txt |   50 -
> >> .../devicetree/bindings/net/nfc/stnfc.txt  |   50 +
> >> drivers/nfc/Kconfig|2 +-
> >> drivers/nfc/Makefile   |2 +-
> >> drivers/nfc/nfcst/Kconfig  |   48 +
> >> drivers/nfc/nfcst/Makefile |   12 +
> >> drivers/nfc/nfcst/core.c   | 1122 +
> >> drivers/nfc/nfcst/spi.c|  492 
> >> drivers/nfc/nfcst/stnfcdev.h   |   70 ++
> >> drivers/nfc/nfcst/uart.c   |  164 +++
> >> drivers/nfc/st95hf/Kconfig |   10 -
> >> drivers/nfc/st95hf/Makefile|6 -
> >> drivers/nfc/st95hf/core.c  | 1273 
> >> 
> >> drivers/nfc/st95hf/spi.c   |  167 ---
> >> drivers/nfc/st95hf/spi.h   |   64 -
> >> include/net/nfc/digital_uart.h |  105 ++
> >> include/uapi/linux/tty.h   |1 +
> >> net/nfc/Kconfig|   12 +
> >> net/nfc/Makefile   |3 +
> >> net/nfc/digital_uart.c |  523 
> >> 20 files changed, 2604 insertions(+), 1572 deletions(-)  delete mode
> >>100644 Documentation/devicetree/bindings/net/nfc/st95hf.txt
> >> create mode 100644 Documentation/devicetree/bindings/net/nfc/stnfc.txt
> >> create mode 100644 drivers/nfc/nfcst/Kconfig  create mode 100644
> >>drivers/nfc/nfcst/Makefile  create mode 100644 drivers/nfc/nfcst/core.c
> >>create mode 100644 drivers/nfc/nfcst/spi.c  create mode 100644
> >>drivers/nfc/nfcst/stnfcdev.h  create mode 100644
> >>drivers/nfc/nfcst/uart.c delete mode 100644 drivers/nfc/st95hf/Kconfig
> >>delete mode 100644 drivers/nfc/st95hf/Makefile  delete mode 100644
> >>drivers/nfc/st95hf/core.c delete mode 100644 drivers/nfc/st95hf/spi.c
> >>delete mode 100644 drivers/nfc/st95hf/spi.h  create mode 100644
> >>include/net/nfc/digital_uart.h create mode 100644
> >>net/nfc/digital_uart.c
> >>
> >>--
> >>1.9.1
> 


Re: [PATCH v2 0/8] NFC: fix device allocation and nfcmrvl crashes

2017-04-26 Thread Samuel Ortiz
Hi Johan,

On Thu, Mar 30, 2017 at 12:15:34PM +0200, Johan Hovold wrote:
> This started out with the observation that the nfcmrvl_uart driver
> unconditionally dereferenced the tty class device despite the fact that
> not every tty has an associated struct device (Unix98 ptys). Some
> further changes were needed in the common nfcmrvl code to fully address
> this, some of which also incidentally fixed a few related bugs (e.g.
> resource leaks in error paths).
> 
> While fixing this I stumbled over a regression in NFC core that lead to
> broken registration error paths and misnamed workqueues.
> 
> Note that this has only been tested by configuring the n_hci line
> discipline for different ttys without any actual NFC hardware connected.
> 
> Johan
> 
> 
> Changes in v2
>  - fix typo in commit message (1/8)
>  - release reset gpio in error paths (3/8)
>  - fix description of patch impact (3/8)
>  - allow gpio 0 to be used for reset signalling (8/8, new)
> 
> 
> Johan Hovold (8):
>   NFC: fix broken device allocation
>   NFC: nfcmrvl_uart: add missing tty-device sanity check
>   NFC: nfcmrvl: do not use device-managed resources
>   NFC: nfcmrvl: use nfc-device for firmware download
>   NFC: nfcmrvl: fix firmware-management initialisation
>   NFC: nfcmrvl_uart: fix device-node leak during probe
>   NFC: nfcmrvl_usb: use interface as phy device
>   NFC: nfcmrvl: allow gpio 0 for reset signalling
Applied, thanks.

Cheers,
Samuel.


Re: [PATCH v5 0/9] NFC: trf7970a: Fixups & convert to desc-based GPIO

2017-04-26 Thread Samuel Ortiz
Hi Mark,

On Tue, Apr 25, 2017 at 03:43:47PM -0700, Mark Greer wrote:
> These trf7970a driver patches do the following things:
>  - add Mark Greer as the maintainer of the trf7970a driver
>  - some minor fixups
>  - remove support for 'vin-voltage-override' DT property
>  - change the DTS example to indicate that EN and EN2 are active high GPIOs
>  - convert the driver to use the descriptor-based GPIO interface
>  - apply Lindent coding style fixes
> 
> Based on nfc-next/master 4ea206395d3a ("nfc: fix get_unaligned_...() misuses")
> 
> v4->v5:
>  - Fixed whitespace issue in "NFC: trf7970a: Clean up coding style issues"
> 
> v3->v4:
>  - Rebased on nfc-next/master because patches in that branch conflict
>with the v3 version of this patch series.
>  - Removed "NFC: trf7970a: Don't manage EN2 when not specified in DT"
>because a similar patch has already been accepted.
>  - Added "NFC: trf7970a: Clean up coding style issues" because the reason
>I removed it in v3 no longer exists.
>  - Reordered the patches to make more sense (I think)
> 
> v2->v3:
>  - Removed "[PATCH v2 5/7] NFC: trf7970a: Clean up coding style issues"
>because it will make merging patches from Geoff Lansberry and others
>hard to apply.  I will resubmit once those patches have been merged
>or rejected.
>  - Added a patch to remove 'vin-voltage-override' DT property support as
>proper DT regulator set up makes it unnecessary.
> 
> v1->v2:
>  - Commit description fixups only; no functional changes.
> 
> Mark Greer (9):
>   MAINTAINERS: NFC: trf7970a: Add Mark Greer as maintainer
>   NFC: trf7970a: Don't de-assert EN2 unless it was asserted
>   NFC: trf7970a: Fix inaccurate comment in trf7970a_probe()
>   NFC: trf7970a: Only check 'en2-rf-quirk' if EN2 is specified
>   NFC: trf7970a: Remove useless comment
>   NFC: trf7970a: Remove support for 'vin-voltage-override' DT property
>   NFC: trf7970a: Enable pins are active high not active low
>   NFC: trf7970a: Convert to descriptor based GPIO interface
>   NFC: trf7970a: Clean up coding style issues
All patches applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [GIT] [4.12] NFC update

2017-04-20 Thread Samuel Ortiz
On Thu, Apr 20, 2017 at 04:15:39PM -0400, David Miller wrote:
> From: Samuel Ortiz <sa...@linux.intel.com>
> Date: Wed, 19 Apr 2017 01:22:31 +0200
> 
> > This is the NFC pull request for 4.12. We have:
> 
> Please CC netdev on all pull requests you'd like me to act upon.
Apologies, I forgot.
I just resent it with netdev cc'ed now.

Cheers,
Samuel.


[GIT] [4.12] NFC update

2017-04-20 Thread Samuel Ortiz
Hi David,

This is the NFC pull request for 4.12. We have:

- Improvements for the pn533 command queue handling and device
  registration order.
- Removal of platform data for the pn544 and st21nfca drivers.
- Additional device tree options to support more trf7970a hardware options.
- Support for Sony's RC-S380P through the port100 driver.
- Removal of the obsolte nfcwilink driver.
- Headers inclusion cleanups (miscdevice.h, unaligned.h) for many drivers.

The following changes since commit eefe06e8ceea88f8397a8df0880ab5ca28dcada6:

  Merge branch 'bpf-prog-testing-framework' (2017-04-01 12:45:58 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next.git 
tags/nfc-next-4.12-1

for you to fetch changes up to 4ea206395d3aede32bab94a75ec573530486fa44:

  nfc: fix get_unaligned_...() misuses (2017-04-17 00:42:22 +0200)


NFC 4.12 pull request

This is the NFC pull request for 4.12. We have:

- Improvements for the pn533 command queue handling and device
  registration order.
- Removal of platform data for the pn544 and st21nfca drivers.
- Additional device tree options to support more trf7970a hardware options.
- Support for Sony's RC-S380P through the port100 driver.
- Removal of the obsolte nfcwilink driver.
- Headers inclusion cleanups (miscdevice.h, unaligned.h) for many drivers.


Al Viro (1):
  nfc: fix get_unaligned_...() misuses

Andrey Rusalin (3):
  NFC: pn533: change order of free_irq and dev unregistration
  NFC: pn533: improve cmd queue handling
  NFC: pn533: change order operations in dev registation

Andy Shevchenko (12):
  NFC: pn544: Get rid of platform data
  NFC: pn544: Convert to use GPIO descriptor
  NFC: pn544: Convert to use devm_request_threaded_irq()
  NFC: pn544: Add GPIO ACPI mapping table
  NFC: pn544: Get rid of code duplication in ->probe()
  NFC: st21nfca: Fix obvious typo when check error code
  NFC: st21nfca: Get rid of platform data
  NFC: st21nfca: Get rid of "interesting" use of interrupt polarity
  NFC: st21nfca: Covert to use GPIO descriptor
  NFC: st21nfca: Use unified device property API meaningfully
  NFC: netlink: Use error code from nfc_activate_target()
  NFC: Add nfc_dbg() macro

Christophe JAILLET (1):
  NFC: st21nfca: Fix potential memory leak

Corentin Labbe (3):
  nfc: nxp-nci: Remove unneeded linux/miscdevice.h include
  nfc: pn544: Remove unneeded linux/miscdevice.h include
  nfc: st21nfca: Remove unneeded linux/miscdevice.h include

Dan Carpenter (1):
  NFC: nfcmrvl: double free on error path

Geliang Tang (1):
  NFC: nfcmrvl: drop duplicate header gpio.h

Geoff Lansberry (2):
  NFC: trf7970a: add device tree option for 27MHz clock
  NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage

Guan Ben (1):
  NFC: Make EN2 pin optional in the TRF7970A driver

Guenter Roeck (1):
  NFC: nxp-nci: Include unaligned.h instead of access_ok.h

Michał Mirosław (1):
  NFC: pn533: use constant off-stack buffer for sending acks

Nicholas Mc Guire (1):
  nfc: nxp-nci: use msleep for long delays

OGAWA Hirofumi (4):
  nfc: Add support RC-S380P to port100
  nfc: Send same info for both of NFC_CMD_GET_DEVICE and 
NFC_EVENT_DEVICE_ADDED
  nfc: Fix RC-S380* needs zero-length packet
  nfc: Fix hangup of RC-S380* in port100_send_ack()

Rob Herring (1):
  NFC: remove TI nfcwilink driver

Samuel Ortiz (1):
  MAINTAINERS: Remove Lauro and Aloisio from the NFC maintainers list

Sudip Mukherjee (1):
  nfc: fdp: fix NULL pointer dereference

Tobias Klauser (1):
  NFC: nfcmrvl: Include unaligned.h instead of access_ok.h

 .../devicetree/bindings/net/nfc/trf7970a.txt   |   8 +-
 MAINTAINERS|   2 -
 drivers/nfc/Kconfig|  11 -
 drivers/nfc/Makefile   |   1 -
 drivers/nfc/fdp/i2c.c  |   6 +-
 drivers/nfc/nfcmrvl/fw_dnld.c  |   7 +-
 drivers/nfc/nfcmrvl/spi.c  |   6 +-
 drivers/nfc/nfcwilink.c| 578 -
 drivers/nfc/nxp-nci/firmware.c |   2 +-
 drivers/nfc/nxp-nci/i2c.c  |   7 +-
 drivers/nfc/pn533/i2c.c|  34 +-
 drivers/nfc/pn533/pn533.c  |  82 +--
 drivers/nfc/pn533/pn533.h  |   1 +
 drivers/nfc/pn533/usb.c|   8 +-
 drivers/nfc/pn544/i2c.c| 221 ++--
 drivers/nfc/port100.c  |  44 +-
 drivers/nfc/st21nfca/core.c|  12 +-
 drivers/nfc/st21nfca/i2c.c | 123 +
 drivers/n

Re: [PATCH] NFC: nfcmrvl: double free on error path

2017-04-19 Thread Samuel Ortiz
On Wed, Apr 19, 2017 at 02:47:34PM +0300, Dan Carpenter wrote:
> On Sun, Apr 02, 2017 at 12:11:17AM +0200, Samuel Ortiz wrote:
> > Hi Dan,
> > 
> > On Wed, Mar 08, 2017 at 08:22:37AM +0300, Dan Carpenter wrote:
> > > The nci_spi_send() function calls kfree_skb(skb) on both error and
> > > success so this extra kfree_skb() is a double free.
> > > 
> > > Fixes: caf6e49bf6d0 ("NFC: nfcmrvl: add spi driver")
> > > Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>
> > > ---
> > > Static analysis.  Not tested.
> > Applied to nfc-next, thanks.
> > 
> 
> This is still not showing up in linux-next.
I sent a pending pull request containing it.

Cheers,
Samuel


Re: [PATCH v2 0/8] NFC: fix device allocation and nfcmrvl crashes

2017-04-18 Thread Samuel Ortiz
Hi Johan,

On Tue, Apr 18, 2017 at 12:09:16PM +0200, Johan Hovold wrote:
> On Thu, Mar 30, 2017 at 12:15:34PM +0200, Johan Hovold wrote:
> > This started out with the observation that the nfcmrvl_uart driver
> > unconditionally dereferenced the tty class device despite the fact that
> > not every tty has an associated struct device (Unix98 ptys). Some
> > further changes were needed in the common nfcmrvl code to fully address
> > this, some of which also incidentally fixed a few related bugs (e.g.
> > resource leaks in error paths).
> > 
> > While fixing this I stumbled over a regression in NFC core that lead to
> > broken registration error paths and misnamed workqueues.
> > 
> > Note that this has only been tested by configuring the n_hci line
> > discipline for different ttys without any actual NFC hardware connected.
> 
> > Johan Hovold (8):
> >   NFC: fix broken device allocation
> >   NFC: nfcmrvl_uart: add missing tty-device sanity check
> >   NFC: nfcmrvl: do not use device-managed resources
> >   NFC: nfcmrvl: use nfc-device for firmware download
> >   NFC: nfcmrvl: fix firmware-management initialisation
> >   NFC: nfcmrvl_uart: fix device-node leak during probe
> >   NFC: nfcmrvl_usb: use interface as phy device
> >   NFC: nfcmrvl: allow gpio 0 for reset signalling
> 
> Any chance of getting these into 4.12, Samuel?
I have yours and Mark Greer patchset pending. I'll push them to nfc-next
and see if I can send another pull request to Dave by the end of this
week.

Cheers,
Samuel.


[GIT] [4.12] NFC update

2017-04-18 Thread Samuel Ortiz
Hi David,

This is the NFC pull request for 4.12. We have:

- Improvements for the pn533 command queue handling and device
  registration order.
- Removal of platform data for the pn544 and st21nfca drivers.
- Additional device tree options to support more trf7970a hardware options.
- Support for Sony's RC-S380P through the port100 driver.
- Removal of the obsolte nfcwilink driver.
- Headers inclusion cleanups (miscdevice.h, unaligned.h) for many drivers.

The following changes since commit eefe06e8ceea88f8397a8df0880ab5ca28dcada6:

  Merge branch 'bpf-prog-testing-framework' (2017-04-01 12:45:58 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next.git 
tags/nfc-next-4.12-1

for you to fetch changes up to 4ea206395d3aede32bab94a75ec573530486fa44:

  nfc: fix get_unaligned_...() misuses (2017-04-17 00:42:22 +0200)


Al Viro (1):
  nfc: fix get_unaligned_...() misuses

Andrey Rusalin (3):
  NFC: pn533: change order of free_irq and dev unregistration
  NFC: pn533: improve cmd queue handling
  NFC: pn533: change order operations in dev registation

Andy Shevchenko (12):
  NFC: pn544: Get rid of platform data
  NFC: pn544: Convert to use GPIO descriptor
  NFC: pn544: Convert to use devm_request_threaded_irq()
  NFC: pn544: Add GPIO ACPI mapping table
  NFC: pn544: Get rid of code duplication in ->probe()
  NFC: st21nfca: Fix obvious typo when check error code
  NFC: st21nfca: Get rid of platform data
  NFC: st21nfca: Get rid of "interesting" use of interrupt polarity
  NFC: st21nfca: Covert to use GPIO descriptor
  NFC: st21nfca: Use unified device property API meaningfully
  NFC: netlink: Use error code from nfc_activate_target()
  NFC: Add nfc_dbg() macro

Christophe JAILLET (1):
  NFC: st21nfca: Fix potential memory leak

Corentin Labbe (3):
  nfc: nxp-nci: Remove unneeded linux/miscdevice.h include
  nfc: pn544: Remove unneeded linux/miscdevice.h include
  nfc: st21nfca: Remove unneeded linux/miscdevice.h include

Dan Carpenter (1):
  NFC: nfcmrvl: double free on error path

Geliang Tang (1):
  NFC: nfcmrvl: drop duplicate header gpio.h

Geoff Lansberry (2):
  NFC: trf7970a: add device tree option for 27MHz clock
  NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage

Guan Ben (1):
  NFC: Make EN2 pin optional in the TRF7970A driver

Guenter Roeck (1):
  NFC: nxp-nci: Include unaligned.h instead of access_ok.h

Michał Mirosław (1):
  NFC: pn533: use constant off-stack buffer for sending acks

Nicholas Mc Guire (1):
  nfc: nxp-nci: use msleep for long delays

OGAWA Hirofumi (4):
  nfc: Add support RC-S380P to port100
  nfc: Send same info for both of NFC_CMD_GET_DEVICE and 
NFC_EVENT_DEVICE_ADDED
  nfc: Fix RC-S380* needs zero-length packet
  nfc: Fix hangup of RC-S380* in port100_send_ack()

Rob Herring (1):
  NFC: remove TI nfcwilink driver

Samuel Ortiz (1):
  MAINTAINERS: Remove Lauro and Aloisio from the NFC maintainers list

Sudip Mukherjee (1):
  nfc: fdp: fix NULL pointer dereference

Tobias Klauser (1):
  NFC: nfcmrvl: Include unaligned.h instead of access_ok.h

 .../devicetree/bindings/net/nfc/trf7970a.txt   |   8 +-
 MAINTAINERS|   2 -
 drivers/nfc/Kconfig|  11 -
 drivers/nfc/Makefile   |   1 -
 drivers/nfc/fdp/i2c.c  |   6 +-
 drivers/nfc/nfcmrvl/fw_dnld.c  |   7 +-
 drivers/nfc/nfcmrvl/spi.c  |   6 +-
 drivers/nfc/nfcwilink.c| 578 -
 drivers/nfc/nxp-nci/firmware.c |   2 +-
 drivers/nfc/nxp-nci/i2c.c  |   7 +-
 drivers/nfc/pn533/i2c.c|  34 +-
 drivers/nfc/pn533/pn533.c  |  82 +--
 drivers/nfc/pn533/pn533.h  |   1 +
 drivers/nfc/pn533/usb.c|   8 +-
 drivers/nfc/pn544/i2c.c| 221 ++--
 drivers/nfc/port100.c  |  44 +-
 drivers/nfc/st21nfca/core.c|  12 +-
 drivers/nfc/st21nfca/i2c.c | 123 +
 drivers/nfc/trf7970a.c |  98 +++-
 include/linux/platform_data/pn544.h|  43 --
 include/linux/platform_data/st21nfca.h |  33 --
 include/net/nfc/nfc.h  |   1 +
 net/nfc/netlink.c  |  24 +-
 23 files changed, 289 insertions(+), 1063 deletions(-)
 delete mode 100644 drivers/nfc/nfcwilink.c
 delete mode 100644 include/linux/platform_data/pn544.h
 delete mode 100644 include/linux/platform_data/st21nfca.h


Re: [PATCH] nfc: fix get_unaligned_...() misuses

2017-04-16 Thread Samuel Ortiz
On Thu, Apr 06, 2017 at 05:58:59PM +0100, Al Viro wrote:
> On Thu, Apr 06, 2017 at 05:48:47PM +0100, Al Viro wrote:
> > * use unaligned.h, not unaligned/access_ok.h
> 
> ... which got misspelled in that patch, sorry...  Fixed variant follows:
> 
> commit b3e79ba1708c9b74781079c9f8617448fce36b51
> Author: Al Viro 
> Date:   Thu Apr 6 12:42:14 2017 -0400
> 
> nfc: fix get_unaligned_...() misuses
> 
> * use unaligned.h, not unaligned/access_ok.h
> * if a local variable of type uint16_t is unaligned, your compiler is 
> FUBAR
> * the whole point of get_unaligned_... is to avoid memcpy + ..._to_cpu().
>   Using it *after* memcpy() (into aligned object, no less) is pointless.
> 
> Signed-off-by: Al Viro 
Partly applied to nfc-next. The unaligned/access_ok.h replacements were
already applied.

Cheers,
Samuel.


Re: [PATCH v2] NFC: pn533: use constant off-stack buffer for sending acks

2017-04-16 Thread Samuel Ortiz
Hi Michał,

On Thu, Apr 06, 2017 at 05:49:02AM +0200, Michał Mirosław wrote:
> fix for WARN:
> 
> usb 3-2.4.1: NFC: Exchanging data failed (error 0x13)
> llcp: nfc_llcp_recv: err -5
> llcp: nfc_llcp_symm_timer: SYMM timeout
> [ cut here ]
> WARNING: CPU: 1 PID: 26397 at .../drivers/usb/core/hcd.c:1584 
> usb_hcd_map_urb_for_dma+0x370/0x550
> transfer buffer not dma capable
> [...]
> Workqueue: events nfc_llcp_timeout_work [nfc]
> Call Trace:
>  ? dump_stack+0x46/0x5a
>  ? __warn+0xb9/0xe0
>  ? warn_slowpath_fmt+0x5a/0x80
>  ? usb_hcd_map_urb_for_dma+0x370/0x550
>  ? usb_hcd_submit_urb+0x2fb/0xa60
>  ? dequeue_entity+0x3f2/0xc30
>  ? pn533_usb_send_ack+0x5d/0x80 [pn533_usb]
>  ? pn533_usb_abort_cmd+0x13/0x20 [pn533_usb]
>  ? pn533_dep_link_down+0x32/0x70 [pn533]
>  ? nfc_dep_link_down+0x87/0xd0 [nfc]
> [...]
> usb 3-2.4.1: NFC: Exchanging data failed (error 0x13)
> llcp: nfc_llcp_recv: err -5
> llcp: nfc_llcp_symm_timer: SYMM timeout
> 
> Signed-off-by: Michał Mirosław 
> ---
> v2:
>   - "un-moved" other declarations
>   - rebased against nfc-next
> ---
>  drivers/nfc/pn533/i2c.c | 2 +-
>  drivers/nfc/pn533/usb.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH v3 1/3] NFC: trf7970a: add device tree option for 27MHz clock

2017-04-05 Thread Samuel Ortiz
Hi Geoff,

On Wed, Dec 21, 2016 at 11:18:32PM -0500, Geoff Lansberry wrote:
> The TRF7970A has configuration options to support hardware designs
> which use a 27.12MHz clock. This commit adds a device tree option
> 'clock-frequency' to support configuring the this chip for default
> 13.56MHz clock or the optional 27.12MHz clock.
> 
> Signed-off-by: Geoff Lansberry 
> ---
>  .../devicetree/bindings/net/nfc/trf7970a.txt   |  2 +
>  drivers/nfc/trf7970a.c | 50 
> +-
>  2 files changed, 41 insertions(+), 11 deletions(-)
Patches #1 and #2 applied to nfc-next. I'll wait for you to rework #3
before merging.

Cheers,
Samuel.


Re: [PATCH] NFC: pn533: use constant off-stack buffer for sending acks

2017-04-05 Thread Samuel Ortiz
Hi Michał,

On Tue, Apr 04, 2017 at 07:09:10AM +0200, Michał Mirosław wrote:
> This fixes following WARNing:
> 
> usb 3-2.4.1: NFC: Exchanging data failed (error 0x13)
> llcp: nfc_llcp_recv: err -5
> llcp: nfc_llcp_symm_timer: SYMM timeout
> [ cut here ]
> WARNING: CPU: 1 PID: 26397 at .../drivers/usb/core/hcd.c:1584 
> usb_hcd_map_urb_for_dma+0x370/0x550
> transfer buffer not dma capable
> [...]
> Workqueue: events nfc_llcp_timeout_work [nfc]
> Call Trace:
>  ? dump_stack+0x46/0x5a
>  ? __warn+0xb9/0xe0
>  ? warn_slowpath_fmt+0x5a/0x80
>  ? usb_hcd_map_urb_for_dma+0x370/0x550
>  ? usb_hcd_submit_urb+0x2fb/0xa60
>  ? dequeue_entity+0x3f2/0xc30
>  ? pn533_usb_send_ack+0x5d/0x80 [pn533_usb]
>  ? pn533_usb_abort_cmd+0x13/0x20 [pn533_usb]
>  ? pn533_dep_link_down+0x32/0x70 [pn533]
>  ? nfc_dep_link_down+0x87/0xd0 [nfc]
> [...]
> usb 3-2.4.1: NFC: Exchanging data failed (error 0x13)
> llcp: nfc_llcp_recv: err -5
> llcp: nfc_llcp_symm_timer: SYMM timeout
> 
> Signed-off-by: Michał Mirosław 
> ---
> 
> Patch against stable linux-4.10.8.
Could you please rebase against nfc-next ?


> diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
> index 1dc89248e58e..35f410797fe4 100644
> --- a/drivers/nfc/pn533/i2c.c
> +++ b/drivers/nfc/pn533/i2c.c
> @@ -49,10 +49,11 @@ struct pn533_i2c_phy {
>  
>  static int pn533_i2c_send_ack(struct pn533 *dev, gfp_t flags)
>  {
> - struct pn533_i2c_phy *phy = dev->phy;
> - struct i2c_client *client = phy->i2c_dev;
> - u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
> + static const u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
>   /* spec 6.2.1.3:  Preamble, SoPC (2), ACK Code (2), Postamble */
> +
> + struct pn533_i2c_phy *phy = dev->phy;
> + struct i2c_client *client = phy->i2c_dev;
Can we please not move those 2 declarations to make the patch less
verbose ?


> diff --git a/drivers/nfc/pn533/usb.c b/drivers/nfc/pn533/usb.c
> index 33ed78be2750..09e1db8e8dc3 100644
> --- a/drivers/nfc/pn533/usb.c
> +++ b/drivers/nfc/pn533/usb.c
> @@ -147,12 +147,13 @@ static int pn533_submit_urb_for_ack(struct 
> pn533_usb_phy *phy, gfp_t flags)
>  
>  static int pn533_usb_send_ack(struct pn533 *dev, gfp_t flags)
>  {
> - struct pn533_usb_phy *phy = dev->phy;
> - u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
> + static const u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
>   /* spec 7.1.1.3:  Preamble, SoPC (2), ACK Code (2), Postamble */
> +
> + struct pn533_usb_phy *phy = dev->phy;
Ditto.

Cheers,
Samuel.


Re: [PATCH v1] NFC: Add nfc_dbg() macro

2017-04-05 Thread Samuel Ortiz
On Wed, Mar 22, 2017 at 09:22:51PM +0200, Andy Shevchenko wrote:
> In some cases nfc_dbg() is useful. Add such macro to a header.
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  include/net/nfc/nfc.h | 1 +
>  1 file changed, 1 insertion(+)
Applied as well.

Cheers,
Samuel.


Re: [PATCH v1] NFC: netlink: Use error code from nfc_activate_target()

2017-04-05 Thread Samuel Ortiz
Hi Andy,

On Wed, Mar 22, 2017 at 09:20:58PM +0200, Andy Shevchenko wrote:
> It looks like a typo to assign a return code to a variable which is not
> used. Found due to a compiler warning:
> 
> net/nfc/netlink.c: In function ‘nfc_genl_activate_target’:
> net/nfc/netlink.c:903:6: warning: variable ‘rc’ set but not used 
> [-Wunused-but-set-variable]
>   int rc;
> ^~
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  net/nfc/netlink.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.

Cheers,
Samuel.


Re: [PATCH v2 1/5] NFC: st21nfca: Fix obvious typo when check error code

2017-04-05 Thread Samuel Ortiz
Hi Andy,

On Tue, Mar 07, 2017 at 12:25:42PM +0200, Andy Shevchenko wrote:
> We return -ENODEV if ACPI provides a GPIO resource. Looks really wrong.
> If it has even been tested?
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/nfc/st21nfca/i2c.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
All 5 patches applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH 0/3] NFC: pn533: fixes for i2c driver

2017-04-01 Thread Samuel Ortiz
Hi Andrey,

On Wed, Dec 28, 2016 at 08:10:56PM +0300, Andrey Rusalin wrote:
> Each of these patches fix some oops that I met during  
> tests of the driver with itead pn532 nfc module.
> 
> First and third patches related to order of initialization driver,
> where interrupt handler was registered before work queues
> were ready to handle it.
> Also iqr was freed already after work queues were deinitialized.
> 
> Second patch originally sent by Michael Thalmeier.
> I reworked a little bit to make it more readable.
> 
> Andrey Rusalin (3):
>   NFC: pn533: change order of free_irq and dev unregistration
>   NFC: pn533: improve cmd queue handling
>   NFC: pn533: change order operations in dev registation
All 3 patches applied, thanks.

Cheers,
Samuel.


Re: [PATCH] nfc: fdp: fix NULL pointer dereference

2017-04-01 Thread Samuel Ortiz
Hi Sudip,

On Tue, Dec 20, 2016 at 09:09:04PM +, Sudip Mukherjee wrote:
> We are checking phy after dereferencing it. We can print the debug
> information after checking it. If phy is NULL then we will get a good
> stack trace to tell us that we are in this irq handler.
> 
> Signed-off-by: Sudip Mukherjee 
> ---
>  drivers/nfc/fdp/i2c.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH] Make EN2 pin optional in the TRF7970A driver

2017-04-01 Thread Samuel Ortiz
Hi Heiko,

On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:
> From: Guan Ben 
> 
> Make the EN2 pin optional. This is useful for boards,
> which have this pin fix wired, for example to ground.
> 
> Signed-off-by: Guan Ben 
> Signed-off-by: Mark Jonas 
> Signed-off-by: Heiko Schocher 
> 
> ---
> 
>  .../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
>  drivers/nfc/trf7970a.c | 26 
> --
>  2 files changed, 16 insertions(+), 14 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH] nfc: nxp-nci: use msleep for long delays

2017-04-01 Thread Samuel Ortiz
Hi Nicholas,

On Sun, Jan 22, 2017 at 01:28:39PM +0100, Nicholas Mc Guire wrote:
> ulseep_range() uses hrtimers and provides no advantage over msleep()
> for larger delays. For this large delay msleep() is preferable.
> 
> Fixes: commit 6be88670fc59 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI 
> driver")
> Link: http://lkml.org/lkml/2017/1/11/377
> Signed-off-by: Nicholas Mc Guire 
> ---
> Problem was found by cocinelle script.
> 
> nxp_nci_i2c_write takes the negative return code as indicator that the
> NFC device was probably in stand-by mode, the first transaction attempt
> woke it up and that after 110ms latest it would be ready to receive.
> Overrunning this time by a few milliseconds will not hurt though so
> msleep() should be fine here.
> 
> Patch was compile tested with: x86_64_defconfig + CONFIG_NFC=m,
> CONFIG_NFC_NCI=m, CONFIG_NFC_NXP_NCI=m, CONFIG_NFC_NXP_NCI_I2C=m
> 
> Patch is against 4.10-rc4 (localversion-next is next-20170120)
> 
>  drivers/nfc/nxp-nci/i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH v2] nfc: don't be making arch specific unaligned decisions at driver level.

2017-04-01 Thread Samuel Ortiz
Hi Paul,

On Mon, Jan 09, 2017 at 12:52:22PM -0500, Paul Gortmaker wrote:
> Currently ia64 fails building allmodconfig with variations of:
> 
>In file included from drivers/nfc/nxp-nci/i2c.c:39:0:
>./include/linux/unaligned/access_ok.h:62:29: error: redefinition of 
> ‘put_unaligned_be64’
> static __always_inline void put_unaligned_be64(u64 val, void *p)
> ^~
>In file included from ./arch/ia64/include/asm/unaligned.h:5:0,
> from ./arch/ia64/include/asm/io.h:22,
> from ./arch/ia64/include/asm/smp.h:20,
> from ./include/linux/smp.h:59,
> from ./include/linux/topology.h:33,
> from ./include/linux/gfp.h:8,
> from ./include/linux/slab.h:14,
> from ./include/linux/resource_ext.h:19,
> from ./include/linux/acpi.h:26,
> from drivers/nfc/nxp-nci/i2c.c:28:
>./include/linux/unaligned/be_byteshift.h:65:20: note: previous definition 
> of ‘put_unaligned_be64’ was here
> static inline void put_unaligned_be64(u64 val, void *p)
>^~
>scripts/Makefile.build:293: recipe for target 'drivers/nfc/nxp-nci/i2c.o' 
> failed
> 
> The easiest explanation for this is to look at the non-arch users in
> the following output:
> 
>linux$git grep include.*access_ok.h
>arch/arm64/crypto/crc32-arm64.c:#include 
>arch/cris/include/asm/unaligned.h:#include 
>arch/m68k/include/asm/unaligned.h:#include 
>arch/mn10300/include/asm/unaligned.h:#include 
>arch/powerpc/include/asm/unaligned.h:#include 
>arch/s390/include/asm/unaligned.h:#include 
>arch/x86/include/asm/unaligned.h:#include 
>drivers/nfc/nfcmrvl/fw_dnld.c:#include 
>drivers/nfc/nxp-nci/firmware.c:#include 
>drivers/nfc/nxp-nci/i2c.c:#include 
>include/asm-generic/unaligned.h:# include 
> 
> Note that nfc is essentially the only non-arch user in the above.
> When it forces use of access_ok.h, it will break any arch that has
> already selected be_byteshift.h (or other conflicting implementations)
> at the arch level.
> 
> The decision of what variant for unaligned access to use needs to be
> left to the arch level and not used at the driver level.  Since not
> all arch will have sourced asm/unaligned.h already, we need to call
> it out and then the arch can give us just the one definition that
> is needed.
> 
> See commit 064106a91be5 ("kernel: add common infrastructure for
> unaligned access") as a reference.
> 
> Cc: Lauro Ramos Venancio <lauro.venan...@openbossa.org>
> Cc: Aloisio Almeida Jr <aloisio.alme...@openbossa.org>
> Cc: Samuel Ortiz <sa...@linux.intel.com>
> Cc: Tony Luck <tony.l...@intel.com>
> Cc: Fenghua Yu <fenghua...@intel.com>
> Cc: linux-i...@vger.kernel.org
> Cc: linux-wireless@vger.kernel.org
> Signed-off-by: Paul Gortmaker <paul.gortma...@windriver.com>
> ---
> 
> [v2: explicitly include asm/uaccess.h since some arch won't be
>  getting any variant of an unaligned access header without it.
>  Build test allmodconfig on x86-64, i386, arm64, ia64. ]
> 
>  drivers/nfc/nfcmrvl/fw_dnld.c  | 2 +-
>  drivers/nfc/nxp-nci/firmware.c | 2 +-
>  drivers/nfc/nxp-nci/i2c.c  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
This build issue is now fixed in nfc-next with a couple of different
patches.

Cheers,
Samuel.


Re: [PATCH] NFC: st21nfca: Fix potential memory leak

2017-04-01 Thread Samuel Ortiz
Hi Christophe,

On Sun, Feb 19, 2017 at 10:58:47AM +0100, Christophe JAILLET wrote:
> If all bits of 'dev_mask' are already set, there is a memory leak because
> 'info' should be freed before returning.
> 
> While fixing it, 'return -ENOMEM' directly if the first kzalloc fails.
> This makes the code more readable.
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/nfc/st21nfca/core.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
Applied, thanks.

Cheers,
Samuel.


Re: [PATCH] NFC: nfcmrvl: double free on error path

2017-04-01 Thread Samuel Ortiz
Hi Dan,

On Wed, Mar 08, 2017 at 08:22:37AM +0300, Dan Carpenter wrote:
> The nci_spi_send() function calls kfree_skb(skb) on both error and
> success so this extra kfree_skb() is a double free.
> 
> Fixes: caf6e49bf6d0 ("NFC: nfcmrvl: add spi driver")
> Signed-off-by: Dan Carpenter 
> ---
> Static analysis.  Not tested.
Applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH 1/3] nfc: nxp-nci: Remove unneeded linux/miscdevice.h include

2017-04-01 Thread Samuel Ortiz
Hi Corentin,

On Thu, Dec 15, 2016 at 03:22:44PM +0100, Corentin Labbe wrote:
> drivers/nfc/nxp-nci/i2c.c does not use any miscdevice, so this patch
> remove this unnecessary inclusion.
> 
> Signed-off-by: Corentin Labbe 
> ---
>  drivers/nfc/nxp-nci/i2c.c | 1 -
>  1 file changed, 1 deletion(-)
All 3 patches applied, thanks.

Cheers,
Samuel.


Re: [PATCH] NFC: nfcmrvl: Include unaligned.h instead of access_ok.h

2017-04-01 Thread Samuel Ortiz
Hi Tobias,

On Wed, Oct 26, 2016 at 11:00:12AM +0200, Tobias Klauser wrote:
> Including linux/unaligned/access_ok.h causes the allmodconfig build on
> ia64 (and maybe others) to fail with the following warnings:
> 
> include/linux/unaligned/access_ok.h:7:19: error: redefinition of 
> 'get_unaligned_le16'
> include/linux/unaligned/access_ok.h:12:19: error: redefinition of 
> 'get_unaligned_le32'
> include/linux/unaligned/access_ok.h:17:19: error: redefinition of 
> 'get_unaligned_le64'
> include/linux/unaligned/access_ok.h:22:19: error: redefinition of 
> 'get_unaligned_be16'
> include/linux/unaligned/access_ok.h:27:19: error: redefinition of 
> 'get_unaligned_be32'
> include/linux/unaligned/access_ok.h:32:19: error: redefinition of 
> 'get_unaligned_be64'
> include/linux/unaligned/access_ok.h:37:20: error: redefinition of 
> 'put_unaligned_le16'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 
> 'put_unaligned_le32'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 
> 'put_unaligned_le64'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 
> 'put_unaligned_be16'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 
> 'put_unaligned_be32'
> include/linux/unaligned/access_ok.h:42:20: error: redefinition of 
> 'put_unaligned_be64'
> 
> Fix these by including asm/unaligned.h instead and leave it up to the
> architecture to decide how to implement unaligned accesses.
> 
> Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support")
> Reported-by: kbuild test robot 
> Link: https://lkml.org/lkml/2016/10/22/247
> Cc: Vincent Cuissard 
> Signed-off-by: Tobias Klauser 
> ---
>  drivers/nfc/nfcmrvl/fw_dnld.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
Applied, with Guenter's patches as well.

Cheers,
Samuel.



Re: [PATCH] NFC: nfcmrvl: drop duplicate header gpio.h

2017-04-01 Thread Samuel Ortiz
Hi Geliang,

On Thu, Nov 24, 2016 at 09:58:34PM +0800, Geliang Tang wrote:
> Drop duplicate header gpio.h from nfcmrvl/spi.c.
> 
> Signed-off-by: Geliang Tang 
> ---
>  drivers/nfc/nfcmrvl/spi.c | 1 -
>  1 file changed, 1 deletion(-)
Patch applied, thanks.

Cheers,
Samuel.


Re: [PATCH v2] nfc: don't be making arch specific unaligned decisions at driver level.

2017-03-29 Thread Samuel Ortiz
Hi Paul,

On Tue, Mar 28, 2017 at 06:55:26PM -0400, Paul Gortmaker wrote:
> On Mon, Jan 9, 2017 at 12:52 PM, Paul Gortmaker
>  wrote:
> > Currently ia64 fails building allmodconfig with variations of:
> >
> >In file included from drivers/nfc/nxp-nci/i2c.c:39:0:
> >./include/linux/unaligned/access_ok.h:62:29: error: redefinition of 
> > ‘put_unaligned_be64’
> > static __always_inline void put_unaligned_be64(u64 val, void *p)
> 
> Hi Samuel,
> 
> Do you require changes on this commit, or are you happy to queue it as is?
> Looking at the NFC git history it seems like you are the right person to ask.
I will queue it later this week, sorry for the lag.

Cheers,
Samuel.


Re: Is NFC subsystem abandoned?

2017-03-24 Thread Samuel Ortiz
Hi Andy,

It's not abandoned. I just got swamped for the past 3 months but things
are slowing down now.
I'll go through my patches backlog during the next 10 days.

Apologies for the delays.

Cheers,
Samuel.

On Fri, Mar 24, 2017 at 06:10:35PM +0200, Andy Shevchenko wrote:
> Hi!
> 
> I have sent couple of versions against couple of drivers in NFC
> subsystem (drivers part) and heard nothing in response from subsystem
> maintainers.
> 
> Is the subsystem abandoned?
> 
> Whom should I send my patches? (There are more anticipated)
> 
> Should I escalate to Linus?
> 
> -- 
> Andy Shevchenko 
> Intel Finland Oy


Re: [PATCH] NFC: remove TI nfcwilink driver

2017-02-27 Thread Samuel Ortiz
Hi Rob,

On Wed, Jan 25, 2017 at 04:23:07PM -0600, Rob Herring wrote:
> It appears that TI WiLink devices including NFC (WL185x/WL189x) never
> shipped. The only information I found were announcements in Feb
> 2012 about the parts. There's been no activity on this driver besided
> common changes since initially added in Jan 2012. There's also no in
> users that instantiate the platform device (nor DT bindings).
> 
> This is a first step in removing TI ST (shared transport) driver in
> favor of extending the BT hci_ll driver to support WL183x chips.
> 
> Cc: Ilan Elias <il...@ti.com>
> Cc: Marcel Holtmann <mar...@holtmann.org>
> Cc: Samuel Ortiz <sa...@linux.intel.com>
> Cc: Lauro Ramos Venancio <lauro.venan...@openbossa.org>
> Cc: Aloisio Almeida Jr <aloisio.alme...@openbossa.org>
> Cc: linux-wireless@vger.kernel.org
> Signed-off-by: Rob Herring <r...@kernel.org>
> ---
>  drivers/nfc/Kconfig |  11 -
>  drivers/nfc/Makefile|   1 -
>  drivers/nfc/nfcwilink.c | 578 
> 
>  3 files changed, 590 deletions(-)
>  delete mode 100644 drivers/nfc/nfcwilink.c
Applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH resend 1/4] nfc: Add support RC-S380P to port100

2017-02-27 Thread Samuel Ortiz
Hi Hirofumi,

On Sat, Feb 04, 2017 at 10:15:22AM +0900, OGAWA Hirofumi wrote:
> 
> 
> Signed-off-by: OGAWA Hirofumi 
> ---
> 
>  drivers/nfc/port100.c |8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
All 4 patches applied, thanks.

Cheers,
Samuel.


Re: [PATCH] NFC: remove TI nfcwilink driver

2017-02-27 Thread Samuel Ortiz
Hi Rob,

On Fri, Feb 24, 2017 at 02:56:48PM -0600, Rob Herring wrote:
> On Wed, Jan 25, 2017 at 11:54 PM, Marcel Holtmann  wrote:
> > Hi Rob,
> >
> >> It appears that TI WiLink devices including NFC (WL185x/WL189x) never
> >> shipped. The only information I found were announcements in Feb
> >> 2012 about the parts. There's been no activity on this driver besided
> >> common changes since initially added in Jan 2012. There's also no in
> >> users that instantiate the platform device (nor DT bindings).
> >>
> >> This is a first step in removing TI ST (shared transport) driver in
> >> favor of extending the BT hci_ll driver to support WL183x chips.
> >
> > since the firmware files TINfcInit_* also never made it into the 
> > linux-firmware tree, I have no idea who is using this driver. I am actually 
> > fine with removing it since it would be easy enough to bring back based on 
> > hci_ll driver once there is hardware to test this on.
> 
> Ping. Someone going to pick up this patch?
I'll take it, I need to catch up with pending NFC patches this week.

Cheers,
Samuel.


Re: [PATCH] NFC: nfcmrvl: constify nfcmrvl_if_ops structures

2016-09-19 Thread Samuel Ortiz
Hi Julia,

On Tue, Aug 09, 2016 at 07:03:50PM +0200, Julia Lawall wrote:
> The nfcmrvl_if_ops structures are never modified, so declare them as const.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  drivers/nfc/nfcmrvl/i2c.c |2 +-
>  drivers/nfc/nfcmrvl/main.c|2 +-
>  drivers/nfc/nfcmrvl/nfcmrvl.h |4 ++--
>  drivers/nfc/nfcmrvl/spi.c |2 +-
>  drivers/nfc/nfcmrvl/uart.c|2 +-
>  drivers/nfc/nfcmrvl/usb.c |2 +-
>  6 files changed, 7 insertions(+), 7 deletions(-)
Applied as well, thanks.

Cheers,
Samuel.


Re: [PATCH] NFC: pn533: constify pn533_phy_ops structures

2016-09-19 Thread Samuel Ortiz
Hi Julia,

On Tue, Aug 09, 2016 at 06:11:02PM +0200, Julia Lawall wrote:
> The pn533_phy_ops are never modified, so declare them as const.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  drivers/nfc/pn533/i2c.c   |2 +-
>  drivers/nfc/pn533/pn533.c |2 +-
>  drivers/nfc/pn533/pn533.h |4 ++--
>  drivers/nfc/pn533/usb.c   |2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.


Re: [PATCH] NFC: Delete owner assignment

2016-09-19 Thread Samuel Ortiz
Hi Markus,

On Mon, Aug 15, 2016 at 09:12:29AM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Mon, 15 Aug 2016 09:00:26 +0200
> 
> The field "owner" is set by core. Thus delete an extra initialisation.
> 
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
> Signed-off-by: Markus Elfring 
> ---
>  drivers/nfc/nfcmrvl/i2c.c | 1 -
>  drivers/nfc/pn533/i2c.c   | 1 -
>  drivers/nfc/s3fwrn5/i2c.c | 1 -
>  3 files changed, 3 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.


[GIT] [4.8] NFC update

2016-07-20 Thread Samuel Ortiz
Hi David,

This is the first NFC pull request for 4.8. We have:

- A fairly large NFC digital stack patchset:
  * RTOX fixes.
  * Proper DEP RWT support.
  * ACK and NACK PDUs handling fixes, in both initiator
and target modes.
  * A few memory leak fixes.

- A conversion of the nfcsim driver to use the digital stack.
  The driver supports the DEP protocol in both NFC-A and NFC-F.

- Error injection through debugfs for the nfcsim driver.

- Improvements to the port100 driver for the Sony USB chipset, in
  particular to the command abort and cancellation code paths.

- A few minor fixes for the pn533, trf7970a and fdp drivers.

The following changes since commit 8186f6e382d8719d0a4bc0ef218c4dd7cf55b496:

  net-next: mediatek: fix compile error inside mtk_poll_controller() 
(2016-07-02 15:22:29 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next.git 
tags/nfc-next-4.8-1

for you to fetch changes up to 2a0fe4fe5bf2a6e2277354e7e8f369a20d881891:

  NFC: nfcsim: Simulate lost frames through debugfs entry (2016-07-19 23:24:49 
+0200)


Colin Ian King (1):
  NFC: set info->ram_patch to NULL when it is released

Dan Carpenter (1):
  NFC: pn533: double free on error in probe()

Denys Vlasenko (1):
  NFC: hci: delete unused nfc_llc_get_rx_head_tail_room()

Geert Uytterhoeven (1):
  NFC: fdp: Detect errors from fdp_nci_create_conn()

Geoff Lansberry (1):
  NFC: trf7970a: add TI recommended write of zero to Register 0x18

Thierry Escande (26):
  NFC: port100: Explicitly set NFC-F framing for NFC-DEP
  NFC: digital: Add a delay between poll cycles
  NFC: llcp: Use dynamic debug for hex dump
  NFC: nfcsim: Make use of the Digital layer
  NFC: llcp: Fix usage of llcp_add_tlv()
  NFC: llcp: Fix 2 memory leaks
  NFC: port100: Don't send a new command if one is still pending
  NFC: port100: Fix the command cancellation process
  NFC: port100: Make port100_abort_cmd() synchronous
  NFC: port100: Abort current command before switching RF off
  NFC: nfcsim: Fix missing dependency on NFC_DIGITAL
  NFC: digital: Fix a memory leak in NFC-F listening mode
  NFC: digital: Rework error handling in DEP_RES response
  NFC: digital: Call pending command callbacks at device unregister
  NFC: digital: Set the command pending flag
  NFC: digital: Abort last command when dep link goes down
  NFC: digital: Fix handling of saved PDU sk_buff pointers
  NFC: digital: Remove useless call to skb_reserve()
  NFC: digital: Fix target DEP_REQ I-PDU handling after ATN PDU
  NFC: digital: Fix ACK & NACK PDUs handling in target mode
  NFC: digital: Rework ACK PDU handling in initiator mode
  NFC: digital: Free supervisor PDUs
  NFC: digital: Add support for NFC DEP Response Waiting Time
  NFC: digital: Fix RTOX supervisor PDU handling
  NFC: nfcsim: Add support for sysfs control entry
  NFC: nfcsim: Simulate lost frames through debugfs entry

 drivers/nfc/Kconfig  |   1 +
 drivers/nfc/fdp/fdp.c|   6 +-
 drivers/nfc/nfcsim.c | 643 ---
 drivers/nfc/pn533/usb.c  |   9 +-
 drivers/nfc/port100.c|  82 +-
 drivers/nfc/trf7970a.c   |   4 +
 include/net/nfc/digital.h|   4 +-
 include/net/nfc/llc.h|   4 -
 net/nfc/digital_core.c   |  28 +-
 net/nfc/digital_dep.c| 316 ++---
 net/nfc/digital_technology.c |  11 +-
 net/nfc/hci/llc.c|  17 +-
 net/nfc/llcp_commands.c  |  23 +-
 net/nfc/llcp_core.c  |   9 +-
 14 files changed, 648 insertions(+), 509 deletions(-)
--
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: [PATCH] NFC: null-ify info->ram_patch when firmware is released

2016-07-19 Thread Samuel Ortiz
Hi Colin,

On Fri, Jul 15, 2016 at 02:00:33PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> When the firmware is released for info->ram_patch currently
> info->otp_patch is being nullified and not info->ram_patch.
> This looks like a cut-n-paste coding error. Fix this by
> nullifing the correct field.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/nfc/fdp/fdp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.
--
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: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status

2016-07-13 Thread Samuel Ortiz
Hi Marcel,

On Wed, Jul 13, 2016 at 11:56:02AM +0100, Marcel Holtmann wrote:
> Hi Mauro,
> 
> >> On mips and parisc:
> >> 
> >>drivers/bluetooth/btwilink.c: In function 'ti_st_open':
> >>drivers/bluetooth/btwilink.c:174:21: warning: overflow in implicit 
> >> constant conversion [-Woverflow]
> >>   hst->reg_status = -EINPROGRESS;
> >> 
> >>drivers/nfc/nfcwilink.c: In function 'nfcwilink_open':
> >>drivers/nfc/nfcwilink.c:396:31: warning: overflow in implicit constant 
> >> conversion [-Woverflow]
> >>  drv->st_register_cb_status = -EINPROGRESS;
> >> 
> >> There are actually two issues:
> >>  1. Whether "char" is signed or unsigned depends on the architecture.
> >> As the completion callback data is used to pass a (negative) error
> >> code, it should always be signed.
> >>  2. EINPROGRESS is 150 on mips, 245 on parisc.
> >> Hence -EINPROGRESS doesn't fit in a signed 8-bit number.
> >> 
> >> Change the callback status from "char" to "int" to fix these.
> >> 
> >> Signed-off-by: Geert Uytterhoeven 
> > 
> > Patch looks sane to me, but who will apply it?
> > 
> > Anyway:
> > 
> > Acked-by: Mauro Carvalho Chehab 
> 
> I can take it through bluetooth-next if there is no objection.
> 
> Samuel, are you fine with that?
Yes, please go ahead.

Cheers,
Samuel.
--
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: [PATCH] nfp: check idx is -ENOSPC before using it is an index

2016-07-11 Thread Samuel Ortiz
Hi Colin,

On Mon, Jul 11, 2016 at 04:46:57PM +0100, Colin King wrote:
> diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
> index e44a7a2..d93d314 100644
> --- a/drivers/nfc/fdp/fdp.c
> +++ b/drivers/nfc/fdp/fdp.c
> @@ -345,7 +345,7 @@ static void fdp_nci_release_firmware(struct nci_dev *ndev)
>  
>   if (info->ram_patch) {
>   release_firmware(info->ram_patch);
> - info->otp_patch = NULL;
> + info->ram_patch = NULL;
>   }
>  }
This chunk is unrelated and also already applied to my nfc-next tree.

Cheers,
Samuel.
--
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: [RESEND] nfc: Drop owner assignment from i2c_driver

2016-05-01 Thread Samuel Ortiz
Hi Krzysztof,

On Wed, Mar 30, 2016 at 09:51:04AM +0900, Krzysztof Kozlowski wrote:
> i2c_driver does not need to set an owner because i2c_register_driver()
> will set it.
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> The coccinelle script which generated the patch was sent here:
> http://www.spinics.net/lists/kernel/msg2029903.html
> ---
>  drivers/nfc/nxp-nci/i2c.c  | 1 -
>  drivers/nfc/pn544/i2c.c| 1 -
>  drivers/nfc/st-nci/i2c.c   | 1 -
>  drivers/nfc/st21nfca/i2c.c | 1 -
>  4 files changed, 4 deletions(-)
Patch applied to nfc-next, thanks.

Cheers,
Samuel.
--
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: [PATCH] nfc: pn544: Drop two useless checks in ACPI probe path

2016-03-03 Thread Samuel Ortiz
Hi Mika,

On Thu, Mar 03, 2016 at 11:26:18AM +0200, Mika Westerberg wrote:
> When pn544_hci_i2c_acpi_request_resources() gets called we already know
> that the entries in ->acpi_match_table have matched ACPI ID of the device.
> In addition I2C client pointer cannot be NULL in any case (otherwise I2C
> core would not call ->probe() for the driver in the first place).
> 
> Drop the two useless checks from the driver.
> 
> Signed-off-by: Mika Westerberg 
> ---
>  drivers/nfc/pn544/i2c.c | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.
--
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: [PATCH v2 net] nfc: use GFP_USER for user-controlled kmalloc

2016-02-24 Thread Samuel Ortiz
Hi Cong,

On Fri, Jan 29, 2016 at 11:24:24AM -0800, Cong Wang wrote:
> These two functions are called in sendmsg path, and the
> 'len' is passed from user-space, so we should not allow
> malicious users to OOM kernel on purpose.
> 
> Reported-by: Dmitry Vyukov <dvyu...@google.com>
> Cc: Lauro Ramos Venancio <lauro.venan...@openbossa.org>
> Cc: Aloisio Almeida Jr <aloisio.alme...@openbossa.org>
> Cc: Samuel Ortiz <sa...@linux.intel.com>
> Signed-off-by: Cong Wang <xiyou.wangc...@gmail.com>
> ---
>  net/nfc/llcp_commands.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.
--
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: [PATCH v2 net] nfc: close a race condition in llcp_sock_getname()

2016-02-24 Thread Samuel Ortiz
Hi Cong,

On Fri, Jan 29, 2016 at 11:37:40AM -0800, Cong Wang wrote:
> llcp_sock_getname() checks llcp_sock->dev to make sure
> llcp_sock is already connected or bound, however, we could
> be in the middle of llcp_sock_bind() where llcp_sock->dev
> is bound and llcp_sock->service_name_len is set,
> but llcp_sock->service_name is not, in this case we would
> lead to copy some bytes from a NULL pointer.
> 
> Just lock the sock since this is not a hot path anyway.
> 
> Reported-by: Dmitry Vyukov <dvyu...@google.com>
> Cc: Lauro Ramos Venancio <lauro.venan...@openbossa.org>
> Cc: Aloisio Almeida Jr <aloisio.alme...@openbossa.org>
> Cc: Samuel Ortiz <sa...@linux.intel.com>
> Signed-off-by: Cong Wang <xiyou.wangc...@gmail.com>
> ---
>  net/nfc/llcp_sock.c | 6 ++
>  1 file changed, 6 insertions(+)
Applied as well, thanks.

Cheers,
Samuel.
--
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: [PATCH v2 net] nfc: use GFP_USER for user-controlled kmalloc

2016-02-24 Thread Samuel Ortiz
On Wed, Feb 24, 2016 at 10:41:29AM -0800, Cong Wang wrote:
> On Fri, Jan 29, 2016 at 11:24 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
> > These two functions are called in sendmsg path, and the
> > 'len' is passed from user-space, so we should not allow
> > malicious users to OOM kernel on purpose.
> >
> > Reported-by: Dmitry Vyukov <dvyu...@google.com>
> > Cc: Lauro Ramos Venancio <lauro.venan...@openbossa.org>
> > Cc: Aloisio Almeida Jr <aloisio.alme...@openbossa.org>
> > Cc: Samuel Ortiz <sa...@linux.intel.com>
> > Signed-off-by: Cong Wang <xiyou.wangc...@gmail.com>
> 
> Ping...
> 
> David, this patch seems still not applied, I guess you expect NFC
> maintainer to take it, but this doesn't happen. Could you take it?
I'll look at it later today.

Cheers,
Samuel.
--
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: [[linux-nfc] PATCH v1.0 1/1] driver: nfc: st95hf: Fix of build error

2015-12-22 Thread Samuel Ortiz
Hi Shikha,

On Tue, Dec 22, 2015 at 04:53:37AM -0500, Shikha Singh wrote:
> Modification in core.c to rename function "irq_handler"
> and "irq_thread_handler" to "st95hf_irq_handler" and
> "st95hf_irq_thread_handler" respectively. This modification
> was done to remove build error.
> 
> Signed-off-by: Shikha Singh 
> ---
>  drivers/nfc/st95hf/core.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.
--
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: [PATCH 2/3] NFC: trf7970a: use to_spi_device

2015-12-22 Thread Samuel Ortiz
Hi Tang,

On Wed, Dec 23, 2015 at 12:18:42AM +0800, Geliang Tang wrote:
> Use to_spi_device() instead of open-coding it.
> 
> Signed-off-by: Geliang Tang 
> ---
>  drivers/nfc/trf7970a.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
Applied and pushed, thanks.

Cheers,
Samuel.

--
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: [linux-nfc] [ PATCH v5 2/3] driver: nfc: Add ST95HF NFC Transceiver support

2015-12-21 Thread Samuel Ortiz
On Mon, Dec 21, 2015 at 11:45:35PM +0100, Samuel Ortiz wrote:
> Hi Shikha,
> 
> On Mon, Dec 21, 2015 at 07:57:23PM +0800, Shikha SINGH wrote:
> > Hello Samuel,
> > Please see my answer below.
> > 
> > >This looks a lot better than the initial version.
> > >I only have one question:
> > >
> > >On Fri, Nov 20, 2015 at 06:40:20AM -0500, Shikha Singh wrote:
> > >> +/*
> > >> + * st95hf_send_recv_cmd() is for sending commands to ST95HF
> > >> + * that are described in the cmd_array[]. It can optionally
> > >> + * receive the response if the cmd request is of type
> > >> + * SYNC. For that to happen caller must pass true to recv_res.
> > >> + * For ASYNC request, recv_res is ignored and the
> > >> + * function will never try to receive the response on behalf
> > >> + * of the caller.
> > >> + */
> > >> +static int st95hf_send_recv_cmd(struct st95hf_context *st95context,
> > >> +enum st95hf_cmd_list cmd,
> > >> +int no_modif,
> > >> +struct param_list *list_array,
> > >> +bool recv_res)
> > >> +{
> > >> +unsigned char spi_cmd_buffer[MAX_CMD_LEN];
> > >> +int i, ret;
> > >> +struct device *dev = >spicontext.spidev->dev;
> > >How do you know this driver is still valid at that point ?
> > >It seems to be a potential corner case against the driver's remove 
> > >function, but
> > >it seems to be a race nevertheless.
> > 
> > st95hf_send_recv_cmd() is a static function that can be called only when a 
> > NFC digital request is submitted to our driver.
> > So in summary, it can be called either from an implemented NFC digital ops 
> > (such as st95hf_switch_rf()) or from the driver's threaded ISR.
> > Now if we see the remove function of the driver i.e. st95hf_remove(), it 
> > waits for all the outstanding NFC digital request to finish via 
> > nfc_digital_unregister_device(stcontext->ddev).
> >
> Yes, that was my main concern but I forgot
> nfc_digital_unregister_device() waits for its command workqueue to be
> emptied before returning. So we're safe.
> 
> All 3 patches applied to nfc-next, thanks.
Just a side note: I removed the 2 calls you had in your driver to BUG()
and replaced them with WARN() calls.
BUG() is really meant for unrecoverable system errors as it crashes the
machine. I don't think an NFC driver should call it.

Cheers,
Samuel.
--
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: [[linux-nfc] PATCH v5 2/3] driver: nfc: Add ST95HF NFC Transceiver support

2015-12-21 Thread Samuel Ortiz
Hi Shikha,

On Mon, Dec 21, 2015 at 07:57:23PM +0800, Shikha SINGH wrote:
> Hello Samuel,
>   Please see my answer below.
>   
> >This looks a lot better than the initial version.
> >I only have one question:
> >
> >On Fri, Nov 20, 2015 at 06:40:20AM -0500, Shikha Singh wrote:
> >> +/*
> >> + * st95hf_send_recv_cmd() is for sending commands to ST95HF
> >> + * that are described in the cmd_array[]. It can optionally
> >> + * receive the response if the cmd request is of type
> >> + * SYNC. For that to happen caller must pass true to recv_res.
> >> + * For ASYNC request, recv_res is ignored and the
> >> + * function will never try to receive the response on behalf
> >> + * of the caller.
> >> + */
> >> +static int st95hf_send_recv_cmd(struct st95hf_context *st95context,
> >> +  enum st95hf_cmd_list cmd,
> >> +  int no_modif,
> >> +  struct param_list *list_array,
> >> +  bool recv_res)
> >> +{
> >> +  unsigned char spi_cmd_buffer[MAX_CMD_LEN];
> >> +  int i, ret;
> >> +  struct device *dev = >spicontext.spidev->dev;
> >How do you know this driver is still valid at that point ?
> >It seems to be a potential corner case against the driver's remove function, 
> >but
> >it seems to be a race nevertheless.
> 
> st95hf_send_recv_cmd() is a static function that can be called only when a 
> NFC digital request is submitted to our driver.
> So in summary, it can be called either from an implemented NFC digital ops 
> (such as st95hf_switch_rf()) or from the driver's threaded ISR.
> Now if we see the remove function of the driver i.e. st95hf_remove(), it 
> waits for all the outstanding NFC digital request to finish via 
> nfc_digital_unregister_device(stcontext->ddev).
>
Yes, that was my main concern but I forgot
nfc_digital_unregister_device() waits for its command workqueue to be
emptied before returning. So we're safe.

All 3 patches applied to nfc-next, thanks.

Cheers,
Samuel.
--
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: [RESEND PATCH] NFC: added the sysfs entry for nfcsim workqueue delay

2015-12-20 Thread Samuel Ortiz
Hi Saurabh,

On Sun, Dec 13, 2015 at 01:34:35PM +0530, Saurabh Sengar wrote:
> added the sysfs entry for nfcsim workqueue delay, as tx_delay
> 
> Signed-off-by: Saurabh Sengar 
> ---
> In case this TODO is not expected to be done, please let me know.
> I wonder after my repeated attempts since last 50 days, I am not able to get 
> a single response.
Apologies for the delay.


> Resending this patch in hope to get some response this time.
> 
>  drivers/nfc/nfcsim.c | 38 +++---
>  1 file changed, 35 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/nfc/nfcsim.c b/drivers/nfc/nfcsim.c
> index 26ac9e5..e77be35 100644
> --- a/drivers/nfc/nfcsim.c
> +++ b/drivers/nfc/nfcsim.c
> @@ -32,6 +32,8 @@
>  #define NFCSIM_POLL_TARGET   2
>  #define NFCSIM_POLL_DUAL (NFCSIM_POLL_INITIATOR | NFCSIM_POLL_TARGET)
>  
> +#define TX_DEFAULT_DELAY 5
> +
>  struct nfcsim {
>   struct nfc_dev *nfc_dev;
>  
> @@ -62,12 +64,41 @@ static struct nfcsim *dev1;
>  
>  static struct workqueue_struct *wq;
>  
> +
> +static int tx_delay = TX_DEFAULT_DELAY;
2 things:

- This actually defines an rx delay as it delays the start of the
  receiving workqueue, so the name should be tx_*. I'm being picky here,
  because with this special driver an Rx delay is implicitely a Tx
  one.
- I'd prefer this to be tunable by device, so it should be defined as an
  additional field in the nfcsim structure (rx_delay ?) and set by default
  to RX_DEFAULT_DELAY from nfcsim_init_dev.

Cheers,
Samuel.
--
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: [[linux-nfc] PATCH v5 2/3] driver: nfc: Add ST95HF NFC Transceiver support

2015-12-20 Thread Samuel Ortiz
Hi Singh,

This looks a lot better than the initial version.
I only have one question:

On Fri, Nov 20, 2015 at 06:40:20AM -0500, Shikha Singh wrote:
> +/*
> + * st95hf_send_recv_cmd() is for sending commands to ST95HF
> + * that are described in the cmd_array[]. It can optionally
> + * receive the response if the cmd request is of type
> + * SYNC. For that to happen caller must pass true to recv_res.
> + * For ASYNC request, recv_res is ignored and the
> + * function will never try to receive the response on behalf
> + * of the caller.
> + */
> +static int st95hf_send_recv_cmd(struct st95hf_context *st95context,
> + enum st95hf_cmd_list cmd,
> + int no_modif,
> + struct param_list *list_array,
> + bool recv_res)
> +{
> + unsigned char spi_cmd_buffer[MAX_CMD_LEN];
> + int i, ret;
> + struct device *dev = >spicontext.spidev->dev;
How do you know this driver is still valid at that point ?
It seems to be a potential corner case against the driver's remove
function, but it seems to be a race nevertheless.

Cheers,
Samuel.
--
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: [PATCH] nfc: s3fwrn5: constify s3fwrn5_phy_ops structures

2015-12-20 Thread Samuel Ortiz
Hi Julia,

On Fri, Nov 13, 2015 at 01:04:41PM +0100, Julia Lawall wrote:
> The s3fwrn5_phy_ops structure is never modified, so declare it as const.
> 
> Done with the help of Coccinelle.
Applied to nfc-next, thanks.

Cheers,
Samuel.
--
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: [PATCH] NFC: nfcmrvl: fix SPI driver dependencies

2015-11-03 Thread Samuel Ortiz
Hi Arnd,

On Tue, Nov 03, 2015 at 03:03:33PM +0100, Arnd Bergmann wrote:
> The newly added nfcmrvl_spi driver uses the spi_nci
> infrastructure, but does not have a Kconfig dependency on
> that, so we can get a link-time error:
> 
> drivers/built-in.o: In function `nfcmrvl_spi_nci_send':
> (.text+0x1428dc): undefined reference to `nci_spi_send'
> drivers/built-in.o: In function `nfcmrvl_spi_probe':
> (.text+0x142a24): undefined reference to `nci_spi_allocate_spi'
> drivers/built-in.o: In function `nfcmrvl_spi_int_irq_thread_fn':
> (.text+0x142abc): undefined reference to `nci_spi_read'
> 
> This clarifies the dependency.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: caf6e49bf6d0 ("NFC: nfcmrvl: add spi driver")
Applied, thanks.

Cheers,
Samuel.
--
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: [PATCH 1/2] NFC: delete null dereference

2015-10-19 Thread Samuel Ortiz
Hi Julia,

On Sat, Oct 17, 2015 at 11:32:19AM +0200, Julia Lawall wrote:
> The exit label performs device_unlock(>dev);, which will fail when dev
> is NULL, and nfc_put_device(dev);, which is not useful when dev is NULL, so
> just exit the function immediately.
> 
> Problem found using scripts/coccinelle/null/deref_null.cocci
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  net/nfc/netlink.c |6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.
--
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: [PATCH] NFC: nfcwilink: Drop a useless static qualifier

2015-10-19 Thread Samuel Ortiz
Hi Christophe,

On Tue, Oct 13, 2015 at 08:31:04AM +0200, Christophe JAILLET wrote:
> There is no need to have the 'struct nfcwilink *drv' variable static in the
> probe function.
> It only wastes a few bytes of memory.
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/nfc/nfcwilink.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks a lot.

Cheers,
Samuel.
--
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: [PATCH] nfc: netlink: avoid NULL pointer dereference on error

2015-10-19 Thread Samuel Ortiz
Hi Vincent,

On Wed, Oct 07, 2015 at 11:33:19AM +0200, Vincent Stehlé wrote:
> The function nfc_genl_llc_sdreq() can dereference the dev pointer while
> it is NULL on its error path. Create a new error handling label to avoid
> that.
> 
> This fixes the following coccinelle error:
> 
>   ./net/nfc/netlink.c:1175:21-24: ERROR: dev is NULL but dereferenced.
> 
> Signed-off-by: Vincent Stehlé <vincent.ste...@laposte.net>
> Cc: Thierry Escande <thierry.esca...@linux.intel.com>
> Cc: Samuel Ortiz <sa...@linux.intel.com>
> ---
>  net/nfc/netlink.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
> index 853172c..51c48f0 100644
> --- a/net/nfc/netlink.c
> +++ b/net/nfc/netlink.c
> @@ -,7 +,7 @@ static int nfc_genl_llc_sdreq(struct sk_buff *skb, 
> struct genl_info *info)
>   dev = nfc_get_device(idx);
>   if (!dev) {
>   rc = -ENODEV;
> - goto exit;
> + goto exit_nodev;
>   }
Julia Lawall sent a better fix that I applied:

-   if (!dev) {
-   rc = -ENODEV;
-   goto exit;
-   }
+   if (!dev)
+   return -ENODEV;

Cheers,
Samuel.
--
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: [PATCH] NFC: nxp-nci: constify nxp_nci_phy_ops structure

2015-10-19 Thread Samuel Ortiz
Hi Julia,

On Sun, Oct 11, 2015 at 01:24:13PM +0200, Julia Lawall wrote:
> The only instance of a nxp_nci_phy_ops structure is never modified.  Thus
> the declaration of the structure and all references to the structure type
> can be made const.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  drivers/nfc/nxp-nci/core.c|3 ++-
>  drivers/nfc/nxp-nci/i2c.c |2 +-
>  drivers/nfc/nxp-nci/nxp-nci.h |5 +++--
>  3 files changed, 6 insertions(+), 4 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.
--
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: [PATCH 1/3] NFC: pn544: Auto-select core module

2015-10-19 Thread Samuel Ortiz
Hi Jean,

On Fri, Sep 25, 2015 at 10:49:36AM +0200, Jean Delvare wrote:
> As I understand it, the core nfc_pn544 module is useless without
> either the I2C or the MEI access module. So hide NFC_PN544 and
> select it automatically if either NFC_PN544_I2C or NFC_PN544_MEI is
> selected.
> 
> This avoids presenting NFC_PN544 when neither NFC_PN544_I2C nor
> NFC_PN544_MEI can be selected.
It also avoids building the core driver when no physical layer has been
selected.

All 3 patches applied to nfc-next, thanks.

Cheers,
Samuel.
--
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: [PATCH v3 0/3] nfc: Add driver for Samsung S3FWRN5 NFC Chip

2015-08-20 Thread Samuel Ortiz
Hi Robert,

On Thu, Aug 20, 2015 at 05:25:59PM +0200, Robert Baldyga wrote:
 Hello,
 
 This patchset adds driver for NFC chip Samsung S3FWRN5. First two patches
 are touching NCI core due to some non-standard chip behaviour.
 
 The first one adds post_setup() handler, which is called after NCI_CORE_INIT
 request. It's because we need to read current firmware version from 
 ndev-manufact_specific_info.
 
 The second one adds nci_core_reset() and nci_core_init() functions which
 are needed to reinit NCI core after updating firmware in pose_setup()
 callback.
 
 Best regards,
 Robert Baldyga
 
 Changelog:
 
 v3:
 - Addressed comments from Samuel Ortiz:
   - Used nci_prop_cmd and nci_prop_ops to handle proprietary requests
   - Refactorized s3fwrn5_i2c_nci_read and s3fwrn5_i2c_fw_read
   - Miscellaneous minor fixes
 - Added patch NFC: nci: Add post_setup handler
 - Added patch NFC: nci: export nci_core_reset and nci_core_init
 
 v2: http://www.spinics.net/lists/linux-wireless/msg139241.html
 - Addressed comments from Paul Bolle
 
 v1: http://www.spinics.net/lists/kernel/msg2044290.html
 
 Robert Baldyga (3):
   NFC: nci: Add post_setup handler
   NFC: nci: export nci_core_reset and nci_core_init
   nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip
All 3 patches applied, thanks.

Cheers,
Samuel.
--
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: [PATCH v2] nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip

2015-08-16 Thread Samuel Ortiz
Hi Robert,

On Thu, Jul 30, 2015 at 04:26:16PM +0200, Robert Baldyga wrote:
 +static int s3fwrn5_firmware_update(struct s3fwrn5_info *info)
 +{
 + u32 version;
 + bool need_update;
 + int ret;
 +
 + ENTER();
We have many tracing tools and frameworks in the kernel, I don't think
this is needed.


 +static int s3fwrn5_nci_send(struct nci_dev *ndev, struct sk_buff *skb)
 +{
 + struct s3fwrn5_info *info = nci_get_drvdata(ndev);
 + int ret;
 +
 + ENTER();
 +
 + mutex_lock(info-mutex);
 +
 + if (s3fwrn5_get_mode(info) != S3FWRN5_MODE_NCI)
Why can't we use this routine in firmware mode ?


 + return -EINVAL;
You must unlock before returning.

 +int s3fwrn5_recv_frame(struct nci_dev *ndev, struct sk_buff *skb,
 + enum s3fwrn5_mode mode)
 +{
 + struct s3fwrn5_info *info = nci_get_drvdata(ndev);
 +
 + switch (mode) {
 + case S3FWRN5_MODE_NCI:
 + return info-custom_nci ?
 + s3fwrn5_nci_recv_frame(ndev, skb) :
 + nci_recv_frame(ndev, skb);
In NCI mode, you should not have any of this logic implemented here, but
rely on the NCI core one instead.

 +int s3fwrn5_fw_get_base_addr(struct s3fwrn5_fw_cmd_get_bootinfo_rsp 
 *bootinfo,
 + u32 *base_addr)
This should be a static routine.


 +{
 + int i;
 + struct {
 + u8 version[4];
 + u32 base_addr;
 + } match[] = {
 + {{0x05, 0x00, 0x00, 0x00}, 0x5000},
 + {{0x05, 0x00, 0x00, 0x01}, 0x3000},
 + {{0x05, 0x00, 0x00, 0x02}, 0x3000},
 + {{0x05, 0x00, 0x00, 0x03}, 0x3000},
 + {{0x05, 0x00, 0x00, 0x05}, 0x3000}
 + };
 +
 + for (i = 0; i  ARRAY_SIZE(match); ++i)
 + if (bootinfo-hw_version[0] == match[i].version[0] 
 + bootinfo-hw_version[1] == match[i].version[1] 
 + bootinfo-hw_version[3] == match[i].version[3]) {
 + *base_addr = match[i].base_addr;
 + return 0;
 + }
 +
 + return -EINVAL;
 +}
 +
 +bool s3fwrn5_fw_is_custom(struct s3fwrn5_fw_cmd_get_bootinfo_rsp *bootinfo)
 +{
 + return !!bootinfo-hw_version[2];
 +}
This should be a static inline routine.


 +static int s3fwrn5_i2c_nci_read(struct s3fwrn5_i2c_phy *phy)
 +{
 + struct nci_ctrl_hdr hdr;
 + struct sk_buff *skb;
 + int ret;
 +
 + ENTER();
 +
 + ret = i2c_master_recv(phy-i2c_dev, (char *)hdr, NCI_CTRL_HDR_SIZE);
 + if (ret  0)
 + return ret;
 +
 + if (ret  NCI_CTRL_HDR_SIZE)
 + return -EBADMSG;
 +
 + skb = alloc_skb(NCI_CTRL_HDR_SIZE + hdr.plen, GFP_KERNEL);
 + if (!skb)
 + return -ENOMEM;
 +
 + memcpy(skb_put(skb, NCI_CTRL_HDR_SIZE), hdr, NCI_CTRL_HDR_SIZE);
 +
 + if (hdr.plen == 0)
 + goto out;
 +
 + ret = i2c_master_recv(phy-i2c_dev, skb_put(skb, hdr.plen), hdr.plen);
 + if (ret != hdr.plen) {
 + kfree_skb(skb);
 + return -EBADMSG;
 + }
 +
 +out:
 + DUMP_SKB(R:, skb);
 +
 + return s3fwrn5_recv_frame(phy-ndev, skb, S3FWRN5_MODE_NCI);
 +}
Please factorize s3fwrn5_i2c_nci_read and s3fwrn5_i2c_fw_read. They
share the same logic, only the header sizes differ.


 +static int s3fwrn5_nci_core_reset(struct s3fwrn5_nci_info *nci_info,
 + struct nci_core_reset_cmd *cmd)
 +{
 + struct nci_core_reset_rsp *nci_rsp;
 + struct sk_buff *msg, *rsp = NULL;
 + int ret;
 +
 + ret = s3fwrn5_nci_prep_cmd(msg, NCI_OP_CORE_RESET_CMD,
 + sizeof(*cmd), cmd);
 + if (ret  0)
 + return ret;
 +
 + ret = s3fwrn5_nci_send_msg(nci_info, msg, rsp);
 + kfree_skb(msg);
 + if (ret  0)
 + goto out;
 +
 + nci_rsp = (void *) rsp-data + NCI_CTRL_HDR_SIZE;
 + if (nci_rsp-status != NCI_STATUS_OK)
 + return -EIO;
 +
 +out:
 + kfree_skb(rsp);
 + return ret;
 +}
Please export an nci_core_reset() command from nci/core.c for that, that
would be a __nci_request(ndev, nci_reset_req) wrapper.
Your prep_cmd and send_msg routines are a duplication of the nci/core.c
code, we should avoid that.


 +static int s3fwrn5_nci_core_init_get_version(struct s3fwrn5_nci_info 
 *nci_info,
 + __u32 *version)
 +{
 + struct nci_core_init_rsp_1 *nci_rsp;
 + struct sk_buff *msg, *rsp = NULL;
 + struct nci_ctrl_hdr *hdr;
 + int ret;
 +
 + ret = s3fwrn5_nci_prep_cmd(msg, NCI_OP_CORE_INIT_CMD, 0, NULL);
 + if (ret  0)
 + return ret;
 +
 + ret = s3fwrn5_nci_send_msg(nci_info, msg, rsp);
 + kfree_skb(msg);
 + if (ret  0)
 + goto out;
 +
 + hdr = (void *) rsp-data;
 + if (hdr-plen != 20) {
 + ret = -EIO;
 + goto out;
 + }
 +
 + nci_rsp = (void *) rsp-data + NCI_CTRL_HDR_SIZE;
 + if (nci_rsp-status != NCI_STATUS_OK) {
 + ret = -EIO;
 + goto out;
 + }
 +
 + memcpy(version, 

Re: [PATCH] Doc:nfc: Fix typo in nfc-hci.txt

2015-06-08 Thread Samuel Ortiz
Hi Msanari,

On Fri, Jun 05, 2015 at 09:38:19PM +0900, Masanari Iida wrote:
 This patch fix a spelling typo in nfc-hci.txt
 
 Signed-off-by: Masanari Iida standby2...@gmail.com
 ---
  Documentation/nfc/nfc-hci.txt | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.

Cheers,
Samuel.
--
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: [PATCH] NFC: nci: hci: Fix releasing uninitialized skbs

2015-06-08 Thread Samuel Ortiz
Hi Joe,

On Sun, May 31, 2015 at 05:44:45PM -0700, Joe Perches wrote:
 Several of these goto exit; uses should be direct returns
 as skb is not yet initialized by nci_hci_get_param().
 
 Miscellanea:
 
 o Use !memcmp instead of memcmp() == 0
 o Remove unnecessary goto from if () {... goto exit;} else {...} exit:
 
 Signed-off-by: Joe Perches j...@perches.com
 ---
  net/nfc/nci/hci.c | 11 +++
  1 file changed, 3 insertions(+), 8 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.
--
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: [PATCH] NFC: PN544: use flags argument of devm_gpiod_get to set direction

2015-06-08 Thread Samuel Ortiz
Hi Uwe,

On Tue, May 19, 2015 at 09:22:56AM +0200, Uwe Kleine-König wrote:
 Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
 which appeared in v3.17-rc1, the gpiod_get* functions take an additional
 parameter that allows to specify direction and initial value for output.
 
 Use this to simplify the driver. Furthermore this is one caller less
 that stops us making the flags argument to gpiod_get*() mandatory.
 
 While touching this also do some minor coding style fixes.
 
 Fixes: 0a5942c8e148 (NFC: Add ACPI support for NXP PN544)
 Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
 ---
  drivers/nfc/pn544/i2c.c | 43 +++
  1 file changed, 11 insertions(+), 32 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.
--
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: [char-misc-next] NFC: microread: drop unused variable

2015-06-08 Thread Samuel Ortiz
Hi Tomas,

On Thu, May 07, 2015 at 04:38:30PM +0300, Tomas Winkler wrote:
 In microread_i2c_irq_thread_fn 'client' set but not used
 
 Cc: Lauro Ramos Venancio lauro.venan...@openbossa.org
 Cc: Aloisio Almeida Jr aloisio.alme...@openbossa.org
 Signed-off-by: Tomas Winkler tomas.wink...@intel.com
 ---
  drivers/nfc/microread/i2c.c | 3 ---
  1 file changed, 3 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.
--
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: [PATCH] drivers/nfc: remove obsolete setting of DEBUG

2015-06-08 Thread Samuel Ortiz
Hi Valentin,

On Tue, Apr 28, 2015 at 11:08:47AM +0200, Valentin Rothberg wrote:
 The CPP identifier 'DEBUG' is not used in the source code of nfc at all,
 so we can safely remove setting it in both Makefiles.
 
 Signed-off-by: Valentin Rothberg valentinrothb...@gmail.com
 ---
 I detected this issue with ./scripts/checkkconfigsymbols.py since
 CONFIG_NFC_DEBUG is not defined in Kconfig.
 ---
  drivers/nfc/Makefile | 2 --
  drivers/nfc/nxp-nci/Makefile | 2 --
  2 files changed, 4 deletions(-)
Applied, with a massaged commit message.

Cheers,
Samuel.
--
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: [linux-nfc] [PATCH 1/8] NFC: NCI: Allow connection close with dev down

2015-05-24 Thread Samuel Ortiz
Hi Robert,

On Tue, Mar 31, 2015 at 05:03:42PM +0300, Robert Dolca wrote:
 On Thu, Mar 26, 2015 at 2:29 AM, Samuel Ortiz sa...@linux.intel.com wrote:
  Hi Robert,
 
  On Tue, Feb 24, 2015 at 12:01:45PM +0200, Robert Dolca wrote:
  By calling __nci_request instead of nci_request allows the driver to use
  the function while initializing the device (setup stage)
 
  Signed-off-by: Robert Dolca robert.do...@intel.com
  ---
   net/nfc/nci/core.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
  index 9575a18..c4dd5d8 100644
  --- a/net/nfc/nci/core.c
  +++ b/net/nfc/nci/core.c
  @@ -558,7 +558,7 @@ static void nci_core_conn_close_req(struct nci_dev 
  *ndev, unsigned long opt)
 
   int nci_core_conn_close(struct nci_dev *ndev, u8 conn_id)
   {
  - return nci_request(ndev, nci_core_conn_close_req, conn_id,
  + return __nci_request(ndev, nci_core_conn_close_req, conn_id,
msecs_to_jiffies(NCI_CMD_TIMEOUT));
  You're fixing your problem by removing the NCI request serialization and
  removing the check for your device being UP.
  I assume you need to open and close a proprietary connection from your
  setup hook ? Then please extend nci_request() to check for both NCI_UP
  and NCI_INIT.
 
 You are right, I am opening and closing a connection from the setup
 function. The setup is called by nci_open_device. At the beginning of
 nci_open_device, req_lock is being acquired and it is release at the
 end of the function. That means that when setup is being called
 req_lock is acuired. As you said I can modify nci_request to check for
 NCI_INIT but it tries to acquire req_lock and it can not succeed.
I see, I thought the issue was only about checking the NCI_* flags.

As a short term solution, I propose you do the following:

a) Export nci_core_conn_create_req, nci_core_conn_close_req and
__nci_request.
b) Call __nci_request() directly from your fdp_nci_close_conn() and
fdp_nci_create_conn() routines.

The long term, scalable fix would be to implement and export an
__nci_send_cmd_sync() routine, that would transparently build an NCI
request and tail it to the ndev req skb queue, and put the caller on a
wait queue. The created request's response callback would then wake the
caller up.

Cheers,
Samuel.
--
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: [linux-nfc] [PATCH 8/8] NFC: Add Intel FieldsPeak NFC solution driver

2015-05-24 Thread Samuel Ortiz
Hi Robert,

On Wed, Apr 01, 2015 at 06:35:31PM +0300, Robert Dolca wrote:
 On Thu, Mar 26, 2015 at 2:30 AM, Samuel Ortiz sa...@linux.intel.com wrote:
  + /* If a patch was applied the new version is checked */
  + if (patched) {
  + r = nci_init(ndev);
  + if (r)
  + goto error;
  +
  + r = fdp_nci_get_versions(ndev);
  + if (r)
  + goto error;
  +
  + if (info-otp_version != info-otp_patch_version ||
  + info-ram_version != info-ram_patch_version) {
  + pr_err(FRP firmware update failed);
  + r = -EINVAL;
  + }
  + }
  +
  + /* Check if the device has VSC */
  + if (fdp_post_fw_vsc_cfg[0]) {
  + /* Set the vendor specific configuration */
  + r = fdp_nci_set_production_data(ndev, fdp_post_fw_vsc_cfg[3],
  + fdp_post_fw_vsc_cfg[4]);
  + if (r)
  + goto error;
  + }
  +
  + /* Set clock type and frequency */
  + r = fdp_nci_set_clock(ndev, 0, 26000);
  + if (r)
  + goto error;
  The version checking, production data setting and clock setting should
  be part of a post setup notification call. Please add an nci_dev
  notify() ops that could get called on certain events, for example when
  NCI is up. Bluetooth's HCI does something along those lines already.
  From this notification hook you could implement this post setup stage.
 
  The idea is for your setup routine to only do firmware update and
  nothing else. It will make it shorter, and thus easier to read as well.
 If the RAM patch wasn't applied successfully the device can't be used
 so the setup function should fail.
 If the production data (specifically the clock frequency) is not set
 the device can not be used. If the user space tries to start polling
 before the notification is sent the polling will fail. Having it
 called later would mean introducing a race condition.
Sure. Then I'd rather have an additional NCI hook (e.g.
ndev-ops-open()) called synchronously after the setup stage that
could fail and make open fail as well. The idea here is to separate the
2 parts of your logic and make the code more readable.

Cheers,
Samuel.
--
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: [linux-nfc] [PATCH 3/8] NFC: NCI: Adds NCI init and reset API for drivers

2015-05-24 Thread Samuel Ortiz
Hi Robert,

On Tue, Mar 31, 2015 at 05:05:53PM +0300, Robert Dolca wrote:
 On Thu, Mar 26, 2015 at 2:29 AM, Samuel Ortiz sa...@linux.intel.com wrote:
  Hi Robert,
 
  On Tue, Feb 24, 2015 at 12:01:47PM +0200, Robert Dolca wrote:
  In order to communicate with the device during the setup
  phase, the driver may need to initialize the device. After
  the setup is done the driver should reset the device to leave
  it in the same state that it was before the setup function
  call.
  I would prefer not to export those symbols, but instead introduce a
  quirk bitmap to let the NCI core know that your device expects the core
  to be initialized before calling the setup ops.
  That would be done from nci_open_device().
 
 As part of the initialization / firmware upgrade procedure the driver
 needs to reset and initialize the NCI connection multiple times.
 Having the connection initialized before calling setup is not enough.
Fair enough, I am ok with exporting those symbols.

BTW after looking at your setup routine, I think this is wrong:

+   /* Load firmware from disk */
+   r = fdp_nci_request_firmware(ndev);
+   if (r)
+   goto error;

You should be able to boot your NFC chipset without a local
patch. If there is one, then you can try patching your device, but
otherwise we should continue with the exisiting one.

Cheers,
Samuel.
--
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: [resend PATCH] nfc: logging neatening

2015-04-07 Thread Samuel Ortiz
Hi Joe,

On Tue, Apr 07, 2015 at 12:17:00AM -0700, Joe Perches wrote:
 Add missing terminating newlines to nfc_info and nfc_err
 to avoid possible interleaving from other messages.
 
 Miscellanea:
 
 o typo fix of unknonwn in message
 o remove unnecessary OOM messages as there's a generic dump_stack()
 o realign arguments
 
 Signed-off-by: Joe Perches j...@perches.com
 ---
 
 Adding Andrew Morton
 Resending after a 8 weeks with no reply/review.
 
  drivers/nfc/microread/i2c.c |  2 +-
  drivers/nfc/nfcmrvl/main.c  |  4 ++--
  drivers/nfc/nfcmrvl/usb.c   | 18 +-
  drivers/nfc/pn533.c |  2 +-
  drivers/nfc/pn544/i2c.c |  7 ++-
  drivers/nfc/port100.c   | 36 ++--
  drivers/nfc/st21nfcb/i2c.c  |  5 +
  drivers/nfc/st21nfcb/ndlc.c |  5 ++---
  8 files changed, 36 insertions(+), 43 deletions(-)
Sorry for the lag. Patch applied to nfc-next now.

Cheers,
Samuel.
--
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: [PATCH 16/16] NFC: pn533: fix error return code

2015-04-05 Thread Samuel Ortiz
Hi Julia,

On Sun, Apr 05, 2015 at 02:06:36PM +0200, Julia Lawall wrote:
 Return a negative error code on failure.
 
 A simplified version of the semantic match that finds this problem is as
 follows: (http://coccinelle.lip6.fr/)
 
 // smpl
 @@
 identifier ret; expression e1,e2;
 @@
 (
 if (\(ret  0\|ret != 0\))
  { ... return ret; }
 |
 ret = 0
 )
 ... when != ret = e1
 when != ret
 *if(...)
 {
   ... when != ret = e2
   when forall
  return ret;
 }
 // /smpl
 
 Signed-off-by: Julia Lawall julia.law...@lip6.fr
 
 ---
  drivers/nfc/pn533.c |4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
Applied, thanks.

Cheers,
Samuel.
--
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: [PATCH 8/8] NFC: Add Intel FieldsPeak NFC solution driver

2015-03-26 Thread Samuel Ortiz
Robert,

Another comment:

On Tue, Feb 24, 2015 at 12:01:52PM +0200, Robert Dolca wrote:
 +static struct i2c_device_id fdp_nci_i2c_id_table[] = {
 + {INT339A, 0},
 + {}
 +};
 +
 +MODULE_DEVICE_TABLE(i2c, fdp_nci_i2c_id_table);
 +
 +
 +static const struct acpi_device_id fdp_nci_i2c_acpi_match[] = {
 + {INT339A, 0},
 + {}
 +};
Why don't we have a MODULE_DEVICE_TABLE(acpi, fdp_nci_i2c_acpi_match);
here ?

Cheers,
Samuel.
--
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: [PATCH 8/8] NFC: Add Intel FieldsPeak NFC solution driver

2015-03-25 Thread Samuel Ortiz
Hi Robert,

On Tue, Feb 24, 2015 at 12:01:52PM +0200, Robert Dolca wrote:
 The device can be enumerated using ACPI using the id INT339A.
Please give us some more details about the device. NCI ? HCI ?
Features ? What does the initial patchset support ?

 +config NFC_FDP
 + tristate Intel FDP NFC driver
 + depends on NFC_NCI
 + select CRC_CCITT
 + default n
 + ---help---
 +   Intel FDP core driver.
What's FDP ?


 +   This is a driver based on the NCI NFC kernel layers.
What does it support ?

 +
 +   To compile this driver as a module, choose m here. The module will
 +   be called pn547.
pn547, that's a typo.

 +#define NCI_OP_PROP_PATCH_CMD 
 nci_opcode_pack(NCI_GID_PROP, 0x08)
 +#define NCI_OP_PROP_SET_PRODUCTION_DATA_CMD  nci_opcode_pack(NCI_GID_PROP, 
 0x23)
 +#define NCI_OP_CORE_GET_CONFIG_CMD   nci_opcode_pack(NCI_GID_CORE, 
 0x03)
This is an NFC Forum spcified command, it should be defined in nci.h.

 +static void fdp_nci_get_version_req(struct nci_dev *ndev, unsigned long opt)
 +{
 + fdp_nci_send_cmd(ndev, NCI_OP_CORE_GET_CONFIG_CMD,
 +  sizeof(nci_core_get_config_otp_ram_version),
 +  nci_core_get_config_otp_ram_version);
I don't think you need the intercept logic, so this should be a
simple wrapper around nci_send_cmd().


 +int fdp_nci_create_conn(struct nci_dev *ndev)
 +{
 + struct fdp_nci_info *info = nci_get_drvdata(ndev);
 + struct core_conn_create_dest_spec_params param;
 +
 + param.type = 0xA0;
 + param.length = 0x00;
Would you please describe what those parameters are for ?


 +
 + return nci_core_conn_create(info-ndev, 0xC2, 1, sizeof(param), param,
Please define 0xC2, #define FDP_FW_UPDATE_DEST 0xC2


 +int fdp_nci_send_patch(struct nci_dev *ndev, u8 type)
 +{
 + struct fdp_nci_info *info = nci_get_drvdata(ndev);
 + const struct firmware *fw;
 + struct sk_buff *skb;
 + unsigned long len;
 + u8 max_size, payload_size;
 + int rc = 0;
 +
 + if ((type == NCI_PATCH_TYPE_OTP  !info-otp_patch) ||
 + (type == NCI_PATCH_TYPE_RAM  !info-ram_patch))
 + return -EINVAL;
 +
 + if (type == NCI_PATCH_TYPE_OTP)
 + fw = info-otp_patch;
 + else
 + fw = info-ram_patch;
 +
 + max_size = nci_conn_max_data_pkt_payload_size(ndev, info-conn_id);
 + if (!max_size)
 + return -EINVAL;
 +
 + len = fw-size;
 +
 + fdp_nci_set_data_pkt_counter(ndev, fdp_nci_send_patch_cb,
 +  DIV_ROUND_UP(fw-size, max_size));
 +
 + while (len) {
 +
 + payload_size = min_t(unsigned long, (unsigned long) max_size,
 +  len);
 +
 + skb = nci_skb_alloc(ndev, (NCI_CTRL_HDR_SIZE + payload_size),
 + GFP_KERNEL);
 + skb_reserve(skb, NCI_CTRL_HDR_SIZE);
 +
 + memcpy(skb_put(skb, payload_size), fw-data + (fw-size - len),
 +payload_size);
Where is your control header set ? How does your boot ROM know how much
bytes are expected ?

 +void fdp_nci_intercept_disable(struct nci_dev *ndev)
 +{
 + struct fdp_nci_info *info = nci_get_drvdata(ndev);
 +
 + pr_info(FDP NCI intercept disabled\n);
 + atomic_set(info-intercept, 0);
 +}
Please remove all the intercept stuff here, go through the NCI core and
have a prop_rx ops called.

 +int fdp_nci_recv_frame(struct nci_dev *ndev, struct sk_buff *skb)
 +{
 + struct fdp_nci_info *info = nci_get_drvdata(ndev);
 +
 + pr_debug(%s\n, __func__);
 +
 + if (atomic_read(info-intercept)) {
 + skb_queue_tail(info-rx_q, skb);
 + schedule_work(info-rx_work);
 + return 0;
 + }
 +
 + return nci_recv_frame(ndev, skb);
 +}
 +EXPORT_SYMBOL(fdp_nci_recv_frame);
Without the intercept stuff, this should only be nci_recv_frame().

 +int fdp_nci_send_cmd(struct nci_dev *ndev, u16 opcode, u8 plen,
 +  void *payload)
 +{
 + fdp_nci_intercept_inc(ndev);
 + return nci_send_cmd(ndev, opcode, plen, payload);
 +}
Ditto

 +int fdp_nci_setup(struct nci_dev *ndev)
 +{
 + /* Format: total length followed by an NCI packet */
 + struct fdp_nci_info *info = nci_get_drvdata(ndev);
 + char fdp_post_fw_vsc_cfg[] = {  0x1A, 0x2F, 0x23, 0x17,
 + 0x00, 0x00, 0x00,
 + 0x00, 0x04, 0x04, 0x2B, 0x20, 0xFF,
 + 0x09, 0x07, 0xFF, 0xFF, 0xFF, 0xFF,
 + 0x02, 0xFF, 0xFF,
 + 0x08, 0x03, 0x00, 0xFF, 0xFF };
 + int r;
 + u8 patched = 0;
 +
 + pr_debug(%s\n, __func__);
 +
 + r = nci_init(ndev);
I won't comment further on the fact that I'd prefer to not export
nci_init().

 + if (r)
 + goto error;
 +
 + /* Get RAM and OTP version */
 + r = 

Re: [PATCH 3/8] NFC: NCI: Adds NCI init and reset API for drivers

2015-03-25 Thread Samuel Ortiz
Hi Robert,

On Tue, Feb 24, 2015 at 12:01:47PM +0200, Robert Dolca wrote:
 In order to communicate with the device during the setup
 phase, the driver may need to initialize the device. After
 the setup is done the driver should reset the device to leave
 it in the same state that it was before the setup function
 call.
I would prefer not to export those symbols, but instead introduce a
quirk bitmap to let the NCI core know that your device expects the core
to be initialized before calling the setup ops.
That would be done from nci_open_device().

Cheers,
Samuel.
--
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: [PATCH 4/8] NFC: NCI: Add a special nci_request for driver

2015-03-25 Thread Samuel Ortiz
Hi Robert,

On Tue, Feb 24, 2015 at 12:01:48PM +0200, Robert Dolca wrote:
 This patch adds nci_request_driver and nci_req_complete_driver
 as a wrapper for __nci_request. When nci_req_complete_driver is
 called it also sets cmd_cnt to 1. This is done because the response is not
 sent to the NFC subsystem so cmd_cnt is not decremented there.
 
 nci_send_cmd was previously exported in order to send commands to
 the device from the driver. It shouldn't be used without
 nci_req_complete_driver because cmd_cnt will have the wrong value.
Any NCI packet should make it to the NCI core first, because the logic
and synchornization between Tx and Rx, commands and response is implemented
there. When exporting this kind of symbols, you're opening a can of worms by
potentially allowing each driver to implement the same kind of logic
that's already implemented in the NCI core.

The solution I'd like to see implemented is the following one: Add 1
additional nci_ops entry for handling proprietary packets on the Rx
path. From your driver perspective, you call nci_recv_frame for each and
every packet that you receive: No intercept, no trap. The core will call
your proprietary packets handler for each packet (NTF or RSP) with a
proprietary GID.
You should then be able to remove all the rx work, rx queue and
intercept logic from your driver.

Cheers,
Samuel.
--
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: [PATCH 3/4] NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver

2015-01-29 Thread Samuel Ortiz
Hi Clement,

On Thu, Jan 22, 2015 at 04:27:39PM +0100, clement.perroch...@effinnov.com wrote:
 From: Clément Perrochaud clement.perroch...@nxp.com
 
 Signed-off-by: Clément Perrochaud clement.perroch...@nxp.com
 Signed-off-by: Clément Perrochaud clement.perroch...@effinnov.com
Are you sure you want both S-O-B lines ?


 +static int nxp_nci_i2c_fw_read(struct nxp_nci_i2c_phy *phy,
 +struct sk_buff **skb)
 +{
 + struct i2c_client *client = phy-i2c_dev;
 + u16 header;
 + size_t frame_len;
 + int r;
 +
 + r = i2c_master_recv(client, (u8 *) header, NXP_NCI_FW_HDR_LEN);
 + if (r  0) {
 + goto fw_read_exit;
 + } else if (r != NXP_NCI_FW_HDR_LEN) {
 + nfc_err(client-dev, Incorrect header length: %u\n, r);
 + r = -EBADMSG;
 + goto fw_read_exit;
 + }
 +
 + frame_len = (get_unaligned_be16(header)  NXP_NCI_FW_FRAME_LEN_MASK) +
 + NXP_NCI_FW_CRC_LEN;
 +
 + *skb = alloc_skb(NXP_NCI_FW_HDR_LEN + frame_len, GFP_KERNEL);
 + if (*skb == NULL) {
 + r = -ENOMEM;
 + goto fw_read_exit;
 + }
 +
 + memcpy(skb_put(*skb, NXP_NCI_FW_HDR_LEN), header, NXP_NCI_FW_HDR_LEN);
 +
 + r = i2c_master_recv(client, skb_put(*skb, frame_len), frame_len);
 + if (r != frame_len) {
 + nfc_err(client-dev,
 + Invalid frame length: %u (expected %u)\n,
 + r, frame_len);
 + r = -EBADMSG;
 + goto fw_read_exit_free_skb;
 + }
 +
 + r = 0;
 + goto fw_read_exit;
return 0; is enough.

 +static int nxp_nci_i2c_nci_read(struct nxp_nci_i2c_phy *phy,
 + struct sk_buff **skb)
 +{
 + struct nci_ctrl_hdr header; /* May actually be a data header */
 + struct i2c_client *client = phy-i2c_dev;
 + int r;
 +
 + r = i2c_master_recv(client, (u8 *) header, NCI_CTRL_HDR_SIZE);
 + if (r  0) {
 + goto nci_read_exit;
 + } else if (r != NCI_CTRL_HDR_SIZE) {
 + nfc_err(client-dev, Incorrect header length: %u\n, r);
 + r = -EBADMSG;
 + goto nci_read_exit;
 + }
 +
 + *skb = alloc_skb(NCI_CTRL_HDR_SIZE + header.plen, GFP_KERNEL);
 + if (*skb == NULL) {
 + r = -ENOMEM;
 + goto nci_read_exit;
 + }
 +
 + memcpy(skb_put(*skb, NCI_CTRL_HDR_SIZE), (void *) header,
 +NCI_CTRL_HDR_SIZE);
 +
 + r = i2c_master_recv(client, skb_put(*skb, header.plen), header.plen);
 + if (r != header.plen) {
 + nfc_err(client-dev,
 + Invalid frame payload length: %u (expected %u)\n,
 + r, header.plen);
 + r = -EBADMSG;
 + goto nci_read_exit_free_skb;
 + }
 +
 + r = 0;
 + goto nci_read_exit;
Ditto.

 +static irqreturn_t nxp_nci_i2c_irq_thread_fn(int irq, void *phy_id)
 +{
 + struct nxp_nci_i2c_phy *phy = phy_id;
 + struct i2c_client *client;
 + struct nxp_nci_info *info;
 +
 + struct sk_buff *skb = NULL;
 + int r = 0;
 +
 + if (!phy || !phy-ndev)
 + goto exit_irq_none;
 +
 + client = phy-i2c_dev;
 +
 + if (!client || irq != client-irq)
 + goto exit_irq_none;
 +
 + if (phy-hard_fault != 0)
 + goto exit_irq_handled;
 +
 + info = nci_get_drvdata(phy-ndev);

You probably want to take the info_lock mutex here.

 + switch (info-mode) {
 + case NXP_NCI_MODE_NCI:
 + r = nxp_nci_i2c_nci_read(phy, skb);
 + break;
 + case NXP_NCI_MODE_FW:
 + r = nxp_nci_i2c_fw_read(phy, skb);
 + break;
 + case NXP_NCI_MODE_COLD:
 + r = -EREMOTEIO;
 + break;
 + }
 +
 + if (r == -EREMOTEIO) {
 + phy-hard_fault = r;
 + skb = NULL;
 + } else if (r  0) {
 + nfc_err(client-dev, Read failed with error %d\n, r);
 + goto exit_irq_handled;
 + }
 +
 + switch (info-mode) {
 + case NXP_NCI_MODE_NCI:
 + nci_recv_frame(phy-ndev, skb);
 + break;
 + case NXP_NCI_MODE_FW:
 + nxp_nci_fw_recv_frame(phy-ndev, skb);
 + break;
 + case NXP_NCI_MODE_COLD:
 + break;
 + }
 +
 +exit_irq_handled:
 + return IRQ_HANDLED;
 +exit_irq_none:
 + WARN_ON_ONCE(1);
 + return IRQ_NONE;
 +}
 +static int nxp_nci_i2c_request_gpios(struct nxp_nci_i2c_phy *phy)
 +{
 + int r;
 +
 + r = gpio_request(phy-gpio_en, nxp_nci_en);
Please use the devm_gpiod_* API so that you don't need to free GPIOs
explicitely.


 + if (r  0)
 + goto err_out;
 +
 + r = gpio_direction_output(phy-gpio_en, 0);
 + if (r  0)
 + goto err_gpio_en;
 +
 + r = gpio_request(phy-gpio_fw, nxp_nci_fw);
 + if (r  0)
 + goto err_gpio_en;
 +
 + r = gpio_direction_output(phy-gpio_fw, 0);
 + if (r  0)
 + goto err_gpio_fw;
 

  1   2   >