Re: [PATCH 1/2] acpi: Fail GED probe when not on hardware-reduced

[Samuel Ortiz]

On Fri, Oct 11, 2019 at 12:38:49PM +0200, Rafael J. Wysocki wrote:
> On Wed, Oct 9, 2019 at 3:04 PM Samuel Ortiz  wrote:
> >
> > The Generic Event Device (GED) is a hardware-reduced platform device.
> 
> No, it is not AFAICS.
It's a little confusing, I was not sure what's the common understanding
and tried to be safe by not having non HW-reduced machines getting a
new device that they've never seen so far.


> The spec doesn't say that GED cannot be used on platforms that aren't
> HW-reduced
I agree.

>  and if evged.c is going to be built in unconditionally, the
> kernel will be able to handle GED regardless.
Ok, perfect then. Does that mean you're ok with the 2nd patch but are
going to drop this one?

Cheers,
Samuel.

[PATCH 2/2] acpi: Always build evged in

[Samuel Ortiz]

From: Arjan van de Ven 

Although the Generic Event Device is a Hardware-reduced platfom device,
it should not be restricted to ACPI_REDUCED_HARDWARE_ONLY.
Kernels supporting both fixed and hardware-reduced ACPI platforms should
be able to probe the GED when dynamically detecting that a platform is
hardware-reduced. For that, the driver must be unconditionally built in.

Signed-off-by: Arjan van de Ven 
Signed-off-by: Samuel Ortiz 
---
 drivers/acpi/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 5d361e4e3405..ef1ac4d127da 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -48,7 +48,7 @@ acpi-y+= acpi_pnp.o
 acpi-$(CONFIG_ARM_AMBA)+= acpi_amba.o
 acpi-y += power.o
 acpi-y += event.o
-acpi-$(CONFIG_ACPI_REDUCED_HARDWARE_ONLY) += evged.o
+acpi-y += evged.o
 acpi-y += sysfs.o
 acpi-y += property.o
 acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
-- 
2.21.0

[PATCH 1/2] acpi: Fail GED probe when not on hardware-reduced

[Samuel Ortiz]

The Generic Event Device (GED) is a hardware-reduced platform device.
Probing this driver on fixed platforms should fail.

Signed-off-by: Samuel Ortiz 
---
 drivers/acpi/evged.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/evged.c b/drivers/acpi/evged.c
index aba0d0027586..55de4b2d2fee 100644
--- a/drivers/acpi/evged.c
+++ b/drivers/acpi/evged.c
@@ -127,6 +127,9 @@ static int ged_probe(struct platform_device *pdev)
struct acpi_ged_device *geddev;
acpi_status acpi_ret;
 
+   if (!acpi_gbl_reduced_hardware)
+   return -ENODEV;
+
geddev = devm_kzalloc(>dev, sizeof(*geddev), GFP_KERNEL);
if (!geddev)
return -ENOMEM;
-- 
2.21.0

[PATCH 0/2] acpi: Unconditional GED build

[Samuel Ortiz]

The Generic Event Device is a hardware-reduced ACPI specific device, but
kernels supporting both fixed and hardware-reduced ACPI hardware should
be able to probe it dynamically.

For that purpose, here are 2 patches:

- The first one makes the GED device probe fail on non hardware-reduced
  platforms.
- The second one disable the conditional evged build.

Arjan van de Ven (1):
  acpi: Always build evged in

Samuel Ortiz (1):
  acpi: Fail GED probe when not on hardware-reduced

 drivers/acpi/Makefile | 2 +-
 drivers/acpi/evged.c  | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

-- 
2.21.0

Re: [PATCH] nfc: st21nfca: use setup_timer instead of init_timer

[Samuel Ortiz]

Hi Colin,

On Fri, Nov 24, 2017 at 01:37:41PM +, Colin King wrote:
> From: Colin Ian King 
> 
> Use setup_timer function instead of initializing timer with the
> function and data fields.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/nfc/st21nfca/se.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.

Re: [PATCH] nfc: st21nfca: use setup_timer instead of init_timer

[Samuel Ortiz]

Hi Colin,

On Fri, Nov 24, 2017 at 01:37:41PM +, Colin King wrote:
> From: Colin Ian King 
> 
> Use setup_timer function instead of initializing timer with the
> function and data fields.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/nfc/st21nfca/se.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.

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

[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: fdp: make struct nci_ops static

[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

[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] nfc: s3fwrn5: make array match static const, reduces object code size

[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

[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 0/8] constify nfc i2c_device_id

[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 v4] NFC: trf7970a: Correct register settings for 27MHz clock

[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: [PATCH v4] NFC: trf7970a: Correct register settings for 27MHz clock

[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: [PATCH] nfc: Add sockaddr length checks before accessing sa_family in bind handlers

[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 sockaddr length checks before accessing sa_family in bind handlers

[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

[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: add NULL checks to avoid potential NULL pointer dereference

[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

[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: nci: remove unnecessary null check

[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

[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: Ensure presence of required attributes in the activate_target netlink handler

[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

[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] nfc: Fix the sockaddr length sanitization in llcp_sock_connect

[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/2] NFC-digital: Adjustments for four function implementations

[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 0/2] NFC-digital: Adjustments for four function implementations

[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 ||

[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] NFC: trf7970a: fix check of clock frequencies, use && instead of ||

[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 v2 0/8] NFC: fix device allocation and nfcmrvl crashes

[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 v2 0/8] NFC: fix device allocation and nfcmrvl crashes

[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 v2 0/8] NFC: fix device allocation and nfcmrvl crashes

[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.

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

[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.

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

[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] nfc: fix get_unaligned_...() misuses

[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 v3 1/3] NFC: trf7970a: add device tree option for 27MHz clock

[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 v3 1/3] NFC: trf7970a: add device tree option for 27MHz clock

[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: fdp: fix NULL pointer dereference

[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] nfc: fdp: fix NULL pointer dereference

[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

[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] Make EN2 pin optional in the TRF7970A driver

[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

[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] nfc: nxp-nci: use msleep for long delays

[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.

[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-wirel...@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 v2] nfc: don't be making arch specific unaligned decisions at driver level.

[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 
> Cc: Aloisio Almeida Jr 
> Cc: Samuel Ortiz 
> Cc: Tony Luck 
> Cc: Fenghua Yu 
> Cc: linux-i...@vger.kernel.org
> Cc: linux-wirel...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 
> ---
> 
> [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

[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: st21nfca: Fix potential memory leak

[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 1/3] nfc: nxp-nci: Remove unneeded linux/miscdevice.h include

[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 1/3] nfc: nxp-nci: Remove unneeded linux/miscdevice.h include

[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

[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: Include unaligned.h instead of access_ok.h

[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

[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] NFC: nfcmrvl: drop duplicate header gpio.h

[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.

[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: [PATCH v2] nfc: don't be making arch specific unaligned decisions at driver level.

[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: [PATCH resend 1/4] nfc: Add support RC-S380P to port100

[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 resend 1/4] nfc: Add support RC-S380P to port100

[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

[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-wirel...@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] NFC: remove TI nfcwilink driver

[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 
> Cc: Marcel Holtmann 
> Cc: Samuel Ortiz 
> Cc: Lauro Ramos Venancio 
> Cc: Aloisio Almeida Jr 
> Cc: linux-wirel...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  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] NFC: remove TI nfcwilink driver

[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: remove TI nfcwilink driver

[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

[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

[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: nfcmrvl: constify nfcmrvl_if_ops structures

[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

[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

[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.

Re: [PATCH] NFC: Delete owner assignment

[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.

Re: [PATCH] NFC: null-ify info->ram_patch when firmware is released

[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.

Re: [PATCH] NFC: null-ify info->ram_patch when firmware is released

[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.

Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status

[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.

Re: [PATCH] drivers: misc: ti-st: Use int instead of fuzzy char for callback status

[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.

Re: [PATCH 08/11] NFC: pn533: reduce output when stopping poll

[Samuel Ortiz]

Hi Michael,

On Thu, Apr 21, 2016 at 04:43:56PM +0200, Michael Thalmeier wrote:
> @@ -1259,7 +1259,8 @@ static int pn533_rf_complete(struct pn533 *dev, void 
> *arg,
>   if (IS_ERR(resp)) {
>   rc = PTR_ERR(resp);
>  
> - nfc_err(dev->dev, "RF setting error %d\n", rc);
> + if (rc != -ENOENT)
> + nfc_err(dev->dev, "RF setting error %d\n", rc);
Why ?


>  
>   return rc;
>   }
> @@ -1416,9 +1417,6 @@ static int pn533_poll_complete(struct pn533 *dev, void 
> *arg,
>   if (IS_ERR(resp)) {
>   rc = PTR_ERR(resp);
>  
> - nfc_err(dev->dev, "%s  Poll complete error %d\n",
> - __func__, rc);
> -
Why are you removing that one ?

Cheers,
Samuel.

Re: [PATCH 07/11] NFC: pn533: improve cmd queue handling

[Samuel Ortiz]

Hi Michael,

On Thu, Apr 21, 2016 at 04:43:55PM +0200, Michael Thalmeier wrote:
> Make sure cmd is set before a frame is passed to the transport layer for
> sending. In addition pn533_send_async_complete checks if cmd is set before
> accessing its members.
> 
> Signed-off-by: Michael Thalmeier 
> ---
>  drivers/nfc/pn533/pn533.c | 54 
> +--
>  1 file changed, 34 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
> index d9c5583..d1cc70a 100644
> --- a/drivers/nfc/pn533/pn533.c
> +++ b/drivers/nfc/pn533/pn533.c
> @@ -383,26 +383,36 @@ static void pn533_build_cmd_frame(struct pn533 *dev, u8 
> cmd_code,
>  static int pn533_send_async_complete(struct pn533 *dev)
>  {
>   struct pn533_cmd *cmd = dev->cmd;
> - int status = cmd->status;
> + int rc = 0;
>  
> - struct sk_buff *req = cmd->req;
> - struct sk_buff *resp = cmd->resp;
> + if (cmd) {
if (!cmd) {
dev_dbg(dev->dev, "%s: cmd not set\n", __func__);
return rc;
}

would make the rest of the code more readable.

Cheers,
Samuel.

Re: [PATCH 06/11] NFC: pn533: usb: fix errors when poll is stopped

[Samuel Ortiz]

Hi Michael,

On Thu, Apr 21, 2016 at 04:43:54PM +0200, Michael Thalmeier wrote:
> When a poll ist stopped we need to kill the out_urb request too before
> starting a new request.
> 
> Additionally check if cmd is set in pn533_recv_ack befor accessing its struct
> members.
I understand those 2 (stopping a poll and cmd being NULL) are not
completely unrelated, but I'd prefer if we could have separate patches
here.

As a matter of fact it seems you're trying to handle a potential NULL
cmd pointer in several of the subsequent patches and I'd like to see all
of those grouped in one patch with an explanation as to why we need to
do this (i.e. how come we can have such pointer being NULL).

Cheers,
Samuel.

Re: [PATCH 08/11] NFC: pn533: reduce output when stopping poll

[Samuel Ortiz]

Hi Michael,

On Thu, Apr 21, 2016 at 04:43:56PM +0200, Michael Thalmeier wrote:
> @@ -1259,7 +1259,8 @@ static int pn533_rf_complete(struct pn533 *dev, void 
> *arg,
>   if (IS_ERR(resp)) {
>   rc = PTR_ERR(resp);
>  
> - nfc_err(dev->dev, "RF setting error %d\n", rc);
> + if (rc != -ENOENT)
> + nfc_err(dev->dev, "RF setting error %d\n", rc);
Why ?


>  
>   return rc;
>   }
> @@ -1416,9 +1417,6 @@ static int pn533_poll_complete(struct pn533 *dev, void 
> *arg,
>   if (IS_ERR(resp)) {
>   rc = PTR_ERR(resp);
>  
> - nfc_err(dev->dev, "%s  Poll complete error %d\n",
> - __func__, rc);
> -
Why are you removing that one ?

Cheers,
Samuel.

Re: [PATCH 07/11] NFC: pn533: improve cmd queue handling

[Samuel Ortiz]

Hi Michael,

On Thu, Apr 21, 2016 at 04:43:55PM +0200, Michael Thalmeier wrote:
> Make sure cmd is set before a frame is passed to the transport layer for
> sending. In addition pn533_send_async_complete checks if cmd is set before
> accessing its members.
> 
> Signed-off-by: Michael Thalmeier 
> ---
>  drivers/nfc/pn533/pn533.c | 54 
> +--
>  1 file changed, 34 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
> index d9c5583..d1cc70a 100644
> --- a/drivers/nfc/pn533/pn533.c
> +++ b/drivers/nfc/pn533/pn533.c
> @@ -383,26 +383,36 @@ static void pn533_build_cmd_frame(struct pn533 *dev, u8 
> cmd_code,
>  static int pn533_send_async_complete(struct pn533 *dev)
>  {
>   struct pn533_cmd *cmd = dev->cmd;
> - int status = cmd->status;
> + int rc = 0;
>  
> - struct sk_buff *req = cmd->req;
> - struct sk_buff *resp = cmd->resp;
> + if (cmd) {
if (!cmd) {
dev_dbg(dev->dev, "%s: cmd not set\n", __func__);
return rc;
}

would make the rest of the code more readable.

Cheers,
Samuel.

Re: [PATCH 06/11] NFC: pn533: usb: fix errors when poll is stopped

[Samuel Ortiz]

Hi Michael,

On Thu, Apr 21, 2016 at 04:43:54PM +0200, Michael Thalmeier wrote:
> When a poll ist stopped we need to kill the out_urb request too before
> starting a new request.
> 
> Additionally check if cmd is set in pn533_recv_ack befor accessing its struct
> members.
I understand those 2 (stopping a poll and cmd being NULL) are not
completely unrelated, but I'd prefer if we could have separate patches
here.

As a matter of fact it seems you're trying to handle a potential NULL
cmd pointer in several of the subsequent patches and I'd like to see all
of those grouped in one patch with an explanation as to why we need to
do this (i.e. how come we can have such pointer being NULL).

Cheers,
Samuel.

Re: [PATCH 09/11] NFC: pn533: use nfc_alloc_recv_skb for skb allocation

[Samuel Ortiz]

Hi Michael,

On Thu, Apr 21, 2016 at 04:43:57PM +0200, Michael Thalmeier wrote:
> When multiple receive frames need to be put together in pn533_build_response
> we need to use nfc_alloc_recv_skb instead of the normal alloc_skb. Otherwise
> the nfc core causes an skb error when it tries to push the status byte in
> front of the data.
> 
> Signed-off-by: Michael Thalmeier 
> ---
>  drivers/nfc/pn533/pn533.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
> index c06d22f..ae13277 100644
> --- a/drivers/nfc/pn533/pn533.c
> +++ b/drivers/nfc/pn533/pn533.c
> @@ -1942,7 +1942,7 @@ static struct sk_buff *pn533_build_response(struct 
> pn533 *dev)
>   dev_dbg(dev->dev, "%s total length %d\n",
>   __func__, skb_len);
>  
> - skb = alloc_skb(skb_len, GFP_KERNEL);
> + skb = nfc_alloc_recv_skb(skb_len, GFP_KERNEL);
That looks reasonable. What surprises me is that I'm pretty sure this
got tested (MI bit set on the Rx path)...
Do you get the error from rawsock_add_header() ?

Cheers,
Samuel.

Re: [PATCH 09/11] NFC: pn533: use nfc_alloc_recv_skb for skb allocation

[Samuel Ortiz]

Hi Michael,

On Thu, Apr 21, 2016 at 04:43:57PM +0200, Michael Thalmeier wrote:
> When multiple receive frames need to be put together in pn533_build_response
> we need to use nfc_alloc_recv_skb instead of the normal alloc_skb. Otherwise
> the nfc core causes an skb error when it tries to push the status byte in
> front of the data.
> 
> Signed-off-by: Michael Thalmeier 
> ---
>  drivers/nfc/pn533/pn533.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
> index c06d22f..ae13277 100644
> --- a/drivers/nfc/pn533/pn533.c
> +++ b/drivers/nfc/pn533/pn533.c
> @@ -1942,7 +1942,7 @@ static struct sk_buff *pn533_build_response(struct 
> pn533 *dev)
>   dev_dbg(dev->dev, "%s total length %d\n",
>   __func__, skb_len);
>  
> - skb = alloc_skb(skb_len, GFP_KERNEL);
> + skb = nfc_alloc_recv_skb(skb_len, GFP_KERNEL);
That looks reasonable. What surprises me is that I'm pretty sure this
got tested (MI bit set on the Rx path)...
Do you get the error from rawsock_add_header() ?

Cheers,
Samuel.

Re: [RESEND] nfc: Drop owner assignment from i2c_driver

[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.

Re: [RESEND] nfc: Drop owner assignment from i2c_driver

[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.

Re: [PATCH] nfc: pn533: Add device tree documentation for i2c phy

[Samuel Ortiz]

Hi Michael,

On Mon, Apr 11, 2016 at 04:36:02PM +0200, Michael Thalmeier wrote:
> Add pn533-i2c phy devicetree documentation
> 
> Signed-off-by: Michael Thalmeier 
> ---
>  .../devicetree/bindings/net/nfc/pn533-i2c.txt  | 31 
> ++
>  1 file changed, 31 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/nfc/pn533-i2c.txt
Thanks. Applied and pushed.

Cheers,
Samuel.

Re: [PATCH] nfc: pn533: Add device tree documentation for i2c phy

[Samuel Ortiz]

Hi Michael,

On Mon, Apr 11, 2016 at 04:36:02PM +0200, Michael Thalmeier wrote:
> Add pn533-i2c phy devicetree documentation
> 
> Signed-off-by: Michael Thalmeier 
> ---
>  .../devicetree/bindings/net/nfc/pn533-i2c.txt  | 31 
> ++
>  1 file changed, 31 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/nfc/pn533-i2c.txt
Thanks. Applied and pushed.

Cheers,
Samuel.

Re: [RFC 0/4] NFC: pn533: support for pn532 via I2C

[Samuel Ortiz]

Hi Michael,

On Fri, Mar 25, 2016 at 03:46:50PM +0100, Michael Thalmeier wrote:
> Michael Thalmeier (4):
>   NFC: pn533: Send ATR_REQ only if NFC_PROTO_NFC_DEP bit is set in
> poll_protocols
>   NFC: pn533: fix deadlock when socket is closed while processing
> command
>   NFC: pn533: Separate pn533 driver in HW dependant and independant
> parts
>   NFC: pn533: add I2C phy driver
This looks very clean, thanks a lot.
I applied and pushed all 4 patches, after cleaning the checkpatch
warnings. I'd like you to address one comment on patch #4 as a
follow up patch.

Cheers,
Samuel.

Re: [RFC 4/4] NFC: pn533: add I2C phy driver

[Samuel Ortiz]

Hi Michael,

On Fri, Mar 25, 2016 at 03:46:54PM +0100, Michael Thalmeier wrote:
> This adds the I2C phy interface for the pn533 driver. This way the driver can
> be used to interact with I2C connected pn532.
> 
> Signed-off-by: Michael Thalmeier 
> ---
>  drivers/nfc/pn533/Kconfig  |  11 ++
>  drivers/nfc/pn533/Makefile |   2 +
>  drivers/nfc/pn533/i2c.c| 277 
> +
>  drivers/nfc/pn533/pn533.c  |  29 +
>  drivers/nfc/pn533/pn533.h  |   2 +
>  5 files changed, 321 insertions(+)
>  create mode 100644 drivers/nfc/pn533/i2c.c
> 
> diff --git a/drivers/nfc/pn533/Kconfig b/drivers/nfc/pn533/Kconfig
> index b5a926e..d94122d 100644
> --- a/drivers/nfc/pn533/Kconfig
> +++ b/drivers/nfc/pn533/Kconfig
> @@ -14,3 +14,14 @@ config NFC_PN533_USB
>  
> If you choose to build a module, it'll be called pn533_usb.
> Say N if unsure.
> +
> +config NFC_PN533_I2C
> + tristate "NFC PN533 device support (I2C)"
> + depends on I2C
> + select NFC_PN533
> + ---help---
> +   This module adds support for the NXP pn533 I2C interface.
> +   Select this if your platform is using the I2C bus.
> +
> +   If you choose to build a module, it'll be called pn533_i2c.
> +   Say N if unsure.
> diff --git a/drivers/nfc/pn533/Makefile b/drivers/nfc/pn533/Makefile
> index 12c6be4..51d24c6 100644
> --- a/drivers/nfc/pn533/Makefile
> +++ b/drivers/nfc/pn533/Makefile
> @@ -2,6 +2,8 @@
>  # Makefile for PN533 NFC driver
>  #
>  pn533_usb-objs  = usb.o
> +pn533_i2c-objs  = i2c.o
>  
>  obj-$(CONFIG_NFC_PN533) += pn533.o
>  obj-$(CONFIG_NFC_PN533_USB) += pn533_usb.o
> +obj-$(CONFIG_NFC_PN533_I2C) += pn533_i2c.o
> diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
> new file mode 100644
> index 000..35066b30
> --- /dev/null
> +++ b/drivers/nfc/pn533/i2c.c
> @@ -0,0 +1,277 @@
> +/*
> + * Driver for NXP PN533 NFC Chip - I2C transport layer
> + *
> + * Copyright (C) 2011 Instituto Nokia de Tecnologia
> + * Copyright (C) 2012-2013 Tieto Poland
> + * Copyright (C) 2016 HALE electronic
> + *
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "pn533.h"
> +
> +#define VERSION "0.1"
> +
> +#define PN533_I2C_DRIVER_NAME "pn533_i2c"
> +
> +struct pn533_i2c_phy {
> + struct i2c_client *i2c_dev;
> + struct pn533 *priv;
> +
> + int hard_fault; /*
> +  * < 0 if hardware error occured (e.g. i2c err)
> +  * and prevents normal operation.
> +  */
> +};
> +
> +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};
> + /* spec 6.2.1.3:  Preamble, SoPC (2), ACK Code (2), Postamble */
> + int rc;
> +
> + rc = i2c_master_send(client, ack, 6);
> +
> + return rc;
> +}
> +
> +static int pn533_i2c_send_frame(struct pn533 *dev,
> + struct sk_buff *out)
> +{
> + struct pn533_i2c_phy *phy = dev->phy;
> + struct i2c_client *client = phy->i2c_dev;
> + int rc;
> +
> + if (phy->hard_fault != 0)
> + return phy->hard_fault;
> +
> + if (phy->priv == NULL)
> + phy->priv = dev;
> +
> + print_hex_dump_debug("PN533_i2c TX: ", DUMP_PREFIX_NONE, 16, 1,
> +  out->data, out->len, false);
> +
> + rc = i2c_master_send(client, out->data, out->len);
> +
> + if (rc == -EREMOTEIO) { /* Retry, chip was in power down */
> + usleep_range(6000, 1);
> + rc = i2c_master_send(client, out->data, out->len);
> + }
> +
> + if (rc >= 0) {
> + if (rc != out->len)
> + rc = -EREMOTEIO;
> + else
> + rc = 0;
> + }
> +
> + return rc;
> +}
> +
> +static void pn533_i2c_abort_cmd(struct pn533 *dev, gfp_t flags)
> +{
> + /* An ack will cancel the last issued command */
> + pn533_i2c_send_ack(dev, flags);
> +
> + /* schedule cmd_complete_work to finish current command execution */
> + if (dev->cmd != NULL)
> +

Re: [RFC 0/4] NFC: pn533: support for pn532 via I2C

[Samuel Ortiz]

Hi Michael,

On Fri, Mar 25, 2016 at 03:46:50PM +0100, Michael Thalmeier wrote:
> Michael Thalmeier (4):
>   NFC: pn533: Send ATR_REQ only if NFC_PROTO_NFC_DEP bit is set in
> poll_protocols
>   NFC: pn533: fix deadlock when socket is closed while processing
> command
>   NFC: pn533: Separate pn533 driver in HW dependant and independant
> parts
>   NFC: pn533: add I2C phy driver
This looks very clean, thanks a lot.
I applied and pushed all 4 patches, after cleaning the checkpatch
warnings. I'd like you to address one comment on patch #4 as a
follow up patch.

Cheers,
Samuel.

Re: [RFC 4/4] NFC: pn533: add I2C phy driver

[Samuel Ortiz]

Hi Michael,

On Fri, Mar 25, 2016 at 03:46:54PM +0100, Michael Thalmeier wrote:
> This adds the I2C phy interface for the pn533 driver. This way the driver can
> be used to interact with I2C connected pn532.
> 
> Signed-off-by: Michael Thalmeier 
> ---
>  drivers/nfc/pn533/Kconfig  |  11 ++
>  drivers/nfc/pn533/Makefile |   2 +
>  drivers/nfc/pn533/i2c.c| 277 
> +
>  drivers/nfc/pn533/pn533.c  |  29 +
>  drivers/nfc/pn533/pn533.h  |   2 +
>  5 files changed, 321 insertions(+)
>  create mode 100644 drivers/nfc/pn533/i2c.c
> 
> diff --git a/drivers/nfc/pn533/Kconfig b/drivers/nfc/pn533/Kconfig
> index b5a926e..d94122d 100644
> --- a/drivers/nfc/pn533/Kconfig
> +++ b/drivers/nfc/pn533/Kconfig
> @@ -14,3 +14,14 @@ config NFC_PN533_USB
>  
> If you choose to build a module, it'll be called pn533_usb.
> Say N if unsure.
> +
> +config NFC_PN533_I2C
> + tristate "NFC PN533 device support (I2C)"
> + depends on I2C
> + select NFC_PN533
> + ---help---
> +   This module adds support for the NXP pn533 I2C interface.
> +   Select this if your platform is using the I2C bus.
> +
> +   If you choose to build a module, it'll be called pn533_i2c.
> +   Say N if unsure.
> diff --git a/drivers/nfc/pn533/Makefile b/drivers/nfc/pn533/Makefile
> index 12c6be4..51d24c6 100644
> --- a/drivers/nfc/pn533/Makefile
> +++ b/drivers/nfc/pn533/Makefile
> @@ -2,6 +2,8 @@
>  # Makefile for PN533 NFC driver
>  #
>  pn533_usb-objs  = usb.o
> +pn533_i2c-objs  = i2c.o
>  
>  obj-$(CONFIG_NFC_PN533) += pn533.o
>  obj-$(CONFIG_NFC_PN533_USB) += pn533_usb.o
> +obj-$(CONFIG_NFC_PN533_I2C) += pn533_i2c.o
> diff --git a/drivers/nfc/pn533/i2c.c b/drivers/nfc/pn533/i2c.c
> new file mode 100644
> index 000..35066b30
> --- /dev/null
> +++ b/drivers/nfc/pn533/i2c.c
> @@ -0,0 +1,277 @@
> +/*
> + * Driver for NXP PN533 NFC Chip - I2C transport layer
> + *
> + * Copyright (C) 2011 Instituto Nokia de Tecnologia
> + * Copyright (C) 2012-2013 Tieto Poland
> + * Copyright (C) 2016 HALE electronic
> + *
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "pn533.h"
> +
> +#define VERSION "0.1"
> +
> +#define PN533_I2C_DRIVER_NAME "pn533_i2c"
> +
> +struct pn533_i2c_phy {
> + struct i2c_client *i2c_dev;
> + struct pn533 *priv;
> +
> + int hard_fault; /*
> +  * < 0 if hardware error occured (e.g. i2c err)
> +  * and prevents normal operation.
> +  */
> +};
> +
> +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};
> + /* spec 6.2.1.3:  Preamble, SoPC (2), ACK Code (2), Postamble */
> + int rc;
> +
> + rc = i2c_master_send(client, ack, 6);
> +
> + return rc;
> +}
> +
> +static int pn533_i2c_send_frame(struct pn533 *dev,
> + struct sk_buff *out)
> +{
> + struct pn533_i2c_phy *phy = dev->phy;
> + struct i2c_client *client = phy->i2c_dev;
> + int rc;
> +
> + if (phy->hard_fault != 0)
> + return phy->hard_fault;
> +
> + if (phy->priv == NULL)
> + phy->priv = dev;
> +
> + print_hex_dump_debug("PN533_i2c TX: ", DUMP_PREFIX_NONE, 16, 1,
> +  out->data, out->len, false);
> +
> + rc = i2c_master_send(client, out->data, out->len);
> +
> + if (rc == -EREMOTEIO) { /* Retry, chip was in power down */
> + usleep_range(6000, 1);
> + rc = i2c_master_send(client, out->data, out->len);
> + }
> +
> + if (rc >= 0) {
> + if (rc != out->len)
> + rc = -EREMOTEIO;
> + else
> + rc = 0;
> + }
> +
> + return rc;
> +}
> +
> +static void pn533_i2c_abort_cmd(struct pn533 *dev, gfp_t flags)
> +{
> + /* An ack will cancel the last issued command */
> + pn533_i2c_send_ack(dev, flags);
> +
> + /* schedule cmd_complete_work to finish current command execution */
> + if (dev->cmd != NULL)
> + dev->cmd->status = 

Re: [PATCH] MAINTAINERS: nfc: s3fwrn5: Add second maintainer

[Samuel Ortiz]

Hi Robert,

On Thu, Mar 10, 2016 at 03:22:43PM +0100, Robert Baldyga wrote:
> Add Krzysztof Opasiak as maintainer of S3FWRN5 driver.
> 
> Signed-off-by: Robert Baldyga 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
Applied to nfc-next.

Cheers,
Samuel.

Re: [PATCH] MAINTAINERS: nfc: s3fwrn5: Add second maintainer

[Samuel Ortiz]

Hi Robert,

On Thu, Mar 10, 2016 at 03:22:43PM +0100, Robert Baldyga wrote:
> Add Krzysztof Opasiak as maintainer of S3FWRN5 driver.
> 
> Signed-off-by: Robert Baldyga 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
Applied to nfc-next.

Cheers,
Samuel.

Re: [PATCH 2/3] NFC: trf7970a: use to_spi_device

[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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] NFC: trf7970a: use to_spi_device

[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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NFC: added the rx delay parameter for nfcsim workqueue

[Samuel Ortiz]

Hi Saurabh,

On Mon, Dec 21, 2015 at 12:29:30AM +0530, Saurabh Sengar wrote:
> added the rx delay parameter as a device tunable parameter.
> 
> Signed-off-by: Saurabh Sengar 
> ---
> This is a follow up patch after the review comments by Samuel Ortiz
> on the initial patch.
> Below is the link to original patch which implemented this parameter
> as sysfs entry:
> https://lkml.org/lkml/2015/12/20/118
>  drivers/nfc/nfcsim.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] nfc: s3fwrn5: constify s3fwrn5_phy_ops structures

[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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH] NFC: added the sysfs entry for nfcsim workqueue delay

[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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NFC: added the rx delay parameter for nfcsim workqueue

[Samuel Ortiz]

Hi Saurabh,

On Mon, Dec 21, 2015 at 12:29:30AM +0530, Saurabh Sengar wrote:
> added the rx delay parameter as a device tunable parameter.
> 
> Signed-off-by: Saurabh Sengar <saurabh.tr...@gmail.com>
> ---
> This is a follow up patch after the review comments by Samuel Ortiz
> on the initial patch.
> Below is the link to original patch which implemented this parameter
> as sysfs entry:
> https://lkml.org/lkml/2015/12/20/118
>  drivers/nfc/nfcsim.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH] NFC: added the sysfs entry for nfcsim workqueue delay

[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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] nfc: s3fwrn5: constify s3fwrn5_phy_ops structures

[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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NFC: nfcmrvl: fix SPI driver dependencies

[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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NFC: nfcmrvl: fix SPI driver dependencies

[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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] NFC: delete null dereference

[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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NFC: nfcwilink: Drop a useless static qualifier

[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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/