linux-toradex.git/drivers/nfc, branch v4.13-rc4 Linux kernel for Apalis and Colibri modules Merge tag 'nfc-next-4.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next 2017-07-01T21:30:39+00:00 David S. Miller davem@davemloft.net 2017-07-01T21:30:39+00:00 283131d20edd6f3629bf258e236aa6e44b1a8e27 Samuel Ortiz says: ==================== NFC 4.13 pull request This is the NFC pull requesy for 4.13. We have: - A conversion to unified device and GPIO APIs for the fdp, pn544, and st{21,-nci} drivers. - A fix for NFC device IDs allocation. - A fix for the nfcmrvl driver firmware download mechanism. - A trf7970a DT and GPIO cleanup and clock setting fix. - A few fixes for potential overflows in the digital and LLCP code. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> 
Samuel Ortiz says:

====================
NFC 4.13 pull request

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

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

Signed-off-by: David S. Miller <davem@davemloft.net>
NFC: trf7970a: Correct register settings for 27MHz clock 2017-06-28T07:16:54+00:00 Geoff Lansberry geoff@kuvee.com 2017-04-27T21:28:46+00:00 bd751808f9ff5e1822c627f6c4283009e66b2e53 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 <geoff@kuvee.com> Acked-by: Mark Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> 
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 <geoff@kuvee.com>
Acked-by: Mark Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
NFC: add NULL checks to avoid potential NULL pointer dereference 2017-06-22T22:34:56+00:00 Gustavo A. R. Silva garsilva@embeddedor.com 2017-05-30T20:43:07+00:00 6f874bafacf053b87887f4149fc117e2b1096138 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 <garsilva@embeddedor.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> 
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 <garsilva@embeddedor.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Revert "NFC: trf7970a: Handle extra byte in response to Type 5 RMB commands" 2017-06-22T22:20:00+00:00 Mark Greer mgreer@animalcreek.com 2017-06-15T17:46:17+00:00 a81d1ab3cad77e20c2df8baef0a35a4980fc511c This reverts commit ab714817d7e891608d31f6996b1e4c43cf2bf342. The original commit was designed to handle a bug in the trf7970a NFC controller where an extra byte was returned in Read Multiple Blocks (RMB) command responses. However, it has become less clear whether it is a bug in the trf7970a or in the tag. In addition, it was assumed that the extra byte was always returned but it turns out that is not always the case. The result is that a byte of good data is trimmed off when the extra byte is not present ultimately causing the neard deamon to fail the read. Since the trf7970a driver does not have the context to know when to trim the byte or not, remove the code from the trf7970a driver all together (and move it up to the neard daemon). This has the added benefit of simplifying the kernel driver and putting the extra complexity into userspace. CC: Rob Herring <robh@kernel.org> CC: devicetree@vger.kernel.org Signed-off-by: Mark Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> 
This reverts commit ab714817d7e891608d31f6996b1e4c43cf2bf342.

The original commit was designed to handle a bug in the trf7970a NFC
controller where an extra byte was returned in Read Multiple Blocks (RMB)
command responses.  However, it has become less clear whether it is a bug
in the trf7970a or in the tag.  In addition, it was assumed that the extra
byte was always returned but it turns out that is not always the case. The
result is that a byte of good data is trimmed off when the extra byte is
not present ultimately causing the neard deamon to fail the read.

Since the trf7970a driver does not have the context to know when to trim
the byte or not, remove the code from the trf7970a driver all together
(and move it up to the neard daemon).  This has the added benefit of
simplifying the kernel driver and putting the extra complexity into
userspace.

CC: Rob Herring <robh@kernel.org>
CC: devicetree@vger.kernel.org
Signed-off-by: Mark Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
NFC: trf7970a: fix check of clock frequencies, use && instead of || 2017-06-22T21:59:01+00:00 Colin Ian King colin.king@canonical.com 2017-04-24T13:36:02+00:00 e1038535106e73e48204ec3bfe5a428fe6cb35cb 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 <colin.king@canonical.com> Acked-by: Geoff Lansberry <geoff@kuvee.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> 
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 <colin.king@canonical.com>
Acked-by: Geoff Lansberry <geoff@kuvee.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
NFC: st-nci: Get rid of code duplication in ->probe() 2017-06-22T21:51:45+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2017-06-19T10:08:57+00:00 c745120e343abfbcf5c9239e09cae4a3cf651fa0 Since OF and ACPI case almost the same get rid of code duplication by moving gpiod_get() calls directly to ->probe(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> 
Since OF and ACPI case almost the same get rid of code duplication
by moving gpiod_get() calls directly to ->probe().

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
NFC: st-nci: Add GPIO ACPI mapping table 2017-06-22T21:51:45+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2017-06-19T10:08:56+00:00 85d23e772931e347c145fa78db3c48f29e169838 In order to make GPIO ACPI library stricter prepare users of gpiod_get_index() to correctly behave when there no mapping is provided by firmware. Here we add explicit mapping between _CRS GpioIo() resources and their names used in the driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> 
In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.

Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
NFC: st-nci: Use unified device properties API meaningfully 2017-06-22T21:51:45+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2017-06-19T10:08:55+00:00 75719b2b7a03729f403aed55bec938c6d2784690 Use unified device properties API in meaningful way. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> 
Use unified device properties API in meaningful way.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
NFC: st-nci: Covert to use GPIO descriptor 2017-06-22T21:51:45+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2017-06-19T10:08:54+00:00 a89e68f118e96b165555f7c64fee8aaff7bb7fb3 Since we got rid of platform data, the driver may use GPIO descriptor directly. Looking deeply to the use of the GPIO pin it looks like it should be a GPIO based reset control rather than custom GPIO handling. But this is out of scope of the change. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> 
Since we got rid of platform data, the driver may use GPIO descriptor
directly.

Looking deeply to the use of the GPIO pin it looks like it should be
a GPIO based reset control rather than custom GPIO handling. But this
is out of scope of the change.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
NFC: st-nci: Get rid of "interesting" use of interrupt polarity 2017-06-22T21:51:45+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2017-06-19T10:08:53+00:00 1af9fea6be9de6e86f628e66c0eae996c49dbe80 I2C and SPI frameworks followed by IRQ framework do set interrupt polarity correctly if it's properly specified in firmware (ACPI or DT). Get rid of the redundant trick when requesting interrupt. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> 
I2C and SPI frameworks followed by IRQ framework do set
interrupt polarity correctly if it's properly specified in firmware
(ACPI or DT).

Get rid of the redundant trick when requesting interrupt.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>