Fix typos and add the following to the scripts/spelling.txt:
omited||omitted
omiting||omitting
Link: http://lkml.kernel.org/r/1481573103-11329-26-git-send-email-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Split callbacks for RX and async notification events on mei bus to
eliminate synchronization problems and to open way for RX optimizations.
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NFC version reply size checked against only header size, not against
full message size. That may lead potentially to uninitialized memory access
in version data.
That leads to warnings when version data is accessed:
drivers/misc/mei/bus-fixup.c: warning: '*((void *)&ver+11)' may be used uninitialized in this function [-Wuninitialized]: => 212:2
Reported in
Build regressions/improvements in v4.9-rc3
https://lkml.org/lkml/2016/10/30/57
Fixes: 59fcd7c63a (mei: nfc: Initial nfc implementation)
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The callback context is redunant as all the information can be
retrived from the device struture of its private data.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In order to remove rather redundant context from the callback
signature we the get nfc mei_phy from the driver's data.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace boilerplate driver registration with module_mei_cl_driver
macro in pn544 and microread devices.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is the first NFC pull request for 4.8. We have:
- A fairly large NFC digital stack patchset:
* RTOX fixes.
* Proper DEP RWT support.
* ACK and NACK PDUs handling fixes, in both initiator
and target modes.
* A few memory leak fixes.
- A conversion of the nfcsim driver to use the digital stack.
The driver supports the DEP protocol in both NFC-A and NFC-F.
- Error injection through debugfs for the nfcsim driver.
- Improvements to the port100 driver for the Sony USB chipset, in
particular to the command abort and cancellation code paths.
- A few minor fixes for the pn533, trf7970a and fdp drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJXjp/3AAoJEIqAPN1PVmxKjpEP/2bgptSwf2cCql+Jv+YaLLny
PjKr+qBXxqvogclucaGg5iIFnVjJ/pHd+csCeqHWpT1jAK7DtK1IJZjg6K9nD7vO
OQQ49+oxcFLTTy00rbfCFzxRaDDnkhD/qafXkTomEMiH7QVK0qssaxm2FVFVEblW
1NTmcsEUnbDbccQhXnxh+N7Xt2CAgsMIbbyHM+4yQuqGtSYjFd164c3jTL13W4a5
SQEJZkCtI7DIdFd6SiXkTGNjlN/fqXuUqXsf2EHxdFb7EE0c067uHpudp2hFdAem
WmAYjjmIuTRFwRFKPJMLUakSen3XbBKVUbtDnIMYykNWYnC4CmedrCrX3YRw4GQt
hZgkj6o5IweSSf6foIgihurE6m5jqd2mAcauwYC/K9wW5nHLaKg8fd9gAngoWY7P
MKBOCyjqIPWkNDC5tne6qftpsDhCrBcdrAtbkorx0lHF20OFto7Gjzxx1Ca+fnJg
N9/fMulQJu8rz3FYpvfvogQMJjkjeFUfyZDa3/ft/ySU6qohxDwXOFaZ82lieTAo
PztTq8tY7GDrdJdyvvHx78RpRVCJT8qHzBRIiiZRpt9MM/aPSepLcozwM97WrJDa
sPvz0jol4d12VIy02j2ArPjMon1MrQePed+Y1y2OtBt8rGiSUxC94t5LE3aMqPs/
a9tNLZYL/nixpLeXbeWa
=yrVP
-----END PGP SIGNATURE-----
Merge tag 'nfc-next-4.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next
Samuel Ortiz says:
====================
NFC 4.8 pull request
This is the first NFC pull request for 4.8. We have:
- A fairly large NFC digital stack patchset:
* RTOX fixes.
* Proper DEP RWT support.
* ACK and NACK PDUs handling fixes, in both initiator
and target modes.
* A few memory leak fixes.
- A conversion of the nfcsim driver to use the digital stack.
The driver supports the DEP protocol in both NFC-A and NFC-F.
- Error injection through debugfs for the nfcsim driver.
- Improvements to the port100 driver for the Sony USB chipset, in
particular to the command abort and cancellation code paths.
- A few minor fixes for the pn533, trf7970a and fdp drivers.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch allows to simulate the lost of frames exchanged between the 2
nfcsim devices through a control entry in the debugfs and is used as
follow:
echo n > /sys/kernel/debug/nfcsim/nfcX/dropframe
Where n specifies the number of frames to be dropped between 0 and 255
and nfcX is either nfc0 or nfc1, one of the two nfcsim devices.
In the following example, the next frame that should be sent by the nfc0
device will be dropped and thus not received by the nfc1 device:
echo 1 > /sys/kernel/debug/nfcsim/nfc0/dropframe
The value of 0 can be used to reset the dropframe counter.
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The idea is to have a way to control and/or modify the behavior of the
nfcsim virtual devices.
This patch creates a folder tree in the debug filesystem. The debugfs is
usually mounted into /sys/kernel/debug and the nfcsim entries are
located in DEBUGFS/nfcsim/nfcX/ where X is either 0 or 1 depending on
the device you want to address.
These folders are empty for now and control entries will be added by
upcoming commits.
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
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 <geert@linux-m68k.org>
Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The nfcsim driver now depends on the Digital layer. This patch adds the
missing dependency on NFC_DIGITAL for NFC_SIM config.
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
If a command is still being processed by the device, the switch RF off
command will be rejected. With this patch, the port100 driver calls
port100_abort_cmd() before sending the switch RF off command.
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This patch makes the abort_cmd function synchronous. This allows the
caller to immediately send a new command after abort_cmd() returns.
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The USB out_urb used to send commands to the device can be submitted
through the standard command processing queue coming from the Digital
Protocol layer but it can also be submitted from port100_abort_cmd().
To not submit the URB while already active, a mutex is now used to
protect it and a cmd_cancel flag is used to not send command while
canceling the previous one.
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This patch ensures that a command is not still in process before sending
a new one to the device. This can happen when neard is in constant
polling mode: the configure_hw command can be sent when neard restarts
polling after a LLCP SYMM timeout but before the device has returned in
timeout from the last DEP frame sent.
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
With this complete rewrite, the loopback nfcsim driver now relies on the
Digital layer of the nfc stack. As with the previous version, 2 nfc
devices are declared when the driver is initialized. The driver supports
the NFC_DEP protocol in NFC-A and NFC-F technologies.
The 2 devices are using a pair of virtual links for sk_buff exchange.
The out-link of one device is the in-link of the other and conversely.
To receive data, a device calls nfcsim_link_recv_skb() on its in-link
and waits for incoming data on a wait queue. To send data, a device
calls nfcsim_link_send_skb() on its out-link which stores the passed skb
and signals its wait queue. If the peer device was in the
nfcsim_link_recv_skb() call, it will be signaled and will be able to
pass the received sk_buff up to the Digital layer.
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When setting the driver framing as NFC_DIGITAL_FRAMING_NFCF_NFC_DEP it
used to be already configured as NFC_DIGITAL_FRAMING_NFCF which is the
same. So this entry was empty in the in_protocols table.
Now that the digital stack can handle PLS requests, it can be changed
on the fly from NFC_DIGITAL_FRAMING_NFCA_NFC_DEP.
This patch explicitly defines the framing configuration values for
NFC_DIGITAL_FRAMING_NFCF_NFC_DEP.
Signed-off-by: Thierry Escande <thierry.escande@collabora.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
drivers/nfc/fdp/fdp.c: In function ‘fdp_nci_patch_otp’:
drivers/nfc/fdp/fdp.c:373: warning: comparison is always false due to limited range of data type
drivers/nfc/fdp/fdp.c: In function ‘fdp_nci_patch_ram’:
drivers/nfc/fdp/fdp.c:444: warning: comparison is always false due to limited range of data type
fdp_nci_create_conn() may return a negative error code, which is
silently ignored by assigning it to a u8.
Change conn_id from u8 to int to fix this.
Fixes: a06347c04c ("NFC: Add Intel Fields Peak NFC solution driver")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
We can't pass devm_ allocated pointers to kfree() because they will be
freed again after the drive is unloaded.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When info->ram_patch is released info->otp_patch is being set
to NULL rather than info->ram_patch. I believe this is a cut-n-paste
bug from almost identical code proceeding it that uses the same
idiom for info->otp_patch.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When pn533_recv_frame is called from within abort_command
context the current dev->cmd is not guaranteed to be set.
Additionally on receiving an error status we can omit frame
checking and simply schedule the workqueue.
Signed-off-by: Michael Thalmeier <michael.thalmeier@hale.at>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
We need to reset the poll modulation list before calling
nfc_targets_found because otherwise userspace could run
before the modulation list is cleared and then get a "Cannot
activate target while polling" error upon calling activate_target.
Signed-off-by: Michael Thalmeier <michael.thalmeier@hale.at>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When a command gets aborted the pn533 core does not need any RX
frames that may be received until a new frame is sent.
Signed-off-by: Michael Thalmeier <michael.thalmeier@hale.at>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Correctly call nfc_set_parent_dev before nfc_register_device.
Otherwise the driver will OOPS when being removed.
Signed-off-by: Michael Thalmeier <michael.thalmeier@hale.at>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The requested irq needs to be freed when removing the driver,
otherwise a following driver load fails to request the irq.
Signed-off-by: Michael Thalmeier <michael.thalmeier@hale.at>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
NCI provides possible way to run loopback testing has done over HCI.
For us it offers many advantages:
- It simplifies the code: No more need for a vendor_cmds structure
- Loopback over HCI may not be supported in future st-nci firmware
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
According to NCI specification, destination type and destination
specific parameters shall uniquely identify a single destination
for the Logical Connection.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
ST21NFCA_ESE_HOST_ID is already defined in st21nfca.h.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
ST_NCI_HCI_HOST_ID_ESE is already having an equivalent in se.c
(ST_NCI_ESE_HOST_ID).
Remove and replace where relevant.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When st_nci_spi_acpi_request_resources() gets called we
already know that the entries in ->acpi_match_table have
matched ACPI ID of the device.
In addition spi_device pointer cannot be NULL in any case
(otherwise SPI core would not call ->probe() for the driver
in the first place).
Drop the two useless checks from the driver.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When st_nci_i2c_acpi_request_resources() gets called we already
know that the entries in ->acpi_match_table have matched ACPI ID
of the device.
In addition I2C client pointer cannot be NULL in any case
(otherwise I2C core would not call ->probe() for the driver in
the first place).
Drop the two useless checks from the driver.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When st21nfca_hci_i2c_acpi_request_resources() gets called we
already know that the entries in ->acpi_match_table have matched
ACPI ID of the device.
In addition I2C client pointer cannot be NULL in any case
(otherwise I2C core would not call ->probe() for the driver in
the first place).
Drop the two useless checks from the driver.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
An APDU_READER_GATE pipe is not expected on a UICC. Be more
explicit so that an other secure element form factor (SD card)
does not prompt this message.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
An APDU_READER_GATE pipe is not expected on a UICC. Be more
explicit so that an other secure element form factor (SD card)
does not prompt this message.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When they're present, set is_ese_present and set is_uicc_present
to the value describe in their package description.
So far is_ese_present and is_uicc_present was set to true if their
property was present.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When they're present, set is_ese_present and set is_uicc_present
to the value describe in their package description.
So far is_ese_present and is_uicc_present was set to true if their
property was present.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Since
commit 10cf4899f8 ("gpiolib: tighten up ACPI legacy gpio lookups")
If _DSD properties are available in an ACPI node, we are not
allowed to fallback to _CRS data to retrieve gpio properties.
This was causing us to fail if uicc-present and/or ese-present
are defined.
To be consistent with devicetree change ST_NCI_GPIO_NAME_RESET
content to reset so that acpi_find_gpio in drivers/gpio/gpiolib.c
will look for reset-gpios. In the mean time the ACPI table needs
to be fixed as follow:
Device (NFC1)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "SMO2100") // _HID: Hardware ID
Name (_CID, "SMO2100") // _CID: Compatible ID
Name (_DDN, "SMO NFC") // _DDN: DOS Device Name
Name (_UID, One) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (SBUF, ResourceTemplate ()
{
I2cSerialBus (0x0008, ControllerInitiated, 400000,
AddressingMode7Bit, "\\_SB.I2C7",
0x00, ResourceConsumer, ,)
GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPO2", 0x00, ResourceConsumer, ,)
{ // Pin list
0x0001
}
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.GPO2", 0x00, ResourceConsumer, ,)
{ // Pin list
0x0002,
}
})
Name (_DSD, Package (0x02)
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x03)
{
Package (0x02) { "uicc-present", 1 },
Package (0x02) { "ese-present", 1 },
Package (0x02) { "enable-gpios", Package(0x04) { ^NFC1, 1, 0, 0} },
}
})
Return (SBUF) /* \_SB_.I2C7.NFC1._CRS.SBUF */
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
}
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Since
commit 10cf4899f8 ("gpiolib: tighten up ACPI legacy gpio lookups")
If _DSD properties are available in an ACPI node, we are not
allowed to fallback to _CRS data to retrieve gpio properties.
This was causing us to fail if uicc-present and/or ese-present
are defined.
To be consistent with devicetree change ST_NCI_GPIO_NAME_RESET
content to reset so that acpi_find_gpio in drivers/gpio/gpiolib.c
will look for reset-gpios. In the mean time the ACPI table needs
to be fixed as follow (Tested on Minnowboard Max):
Device (NFC1)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "SMO2101") // _HID: Hardware ID
Name (_CID, "SMO2101") // _CID: Compatible ID
Name (_DDN, "SMO NFC") // _DDN: DOS Device Name
Name (_UID, One) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (SBUF, ResourceTemplate ()
{
SpiSerialBus (0, PolarityLow, FourWireMode, 8,
ControllerInitiated, 4000000, ClockPolarityLow,
ClockPhaseFirst, "\\_SB.SPI1",
0x00, ResourceConsumer, ,)
GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPO2", 0x00, ResourceConsumer, ,)
{ // Pin list
0x0001
}
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.GPO2", 0x00, ResourceConsumer, ,)
{ // Pin list
0x0002,
}
})
Name (_DSD, Package (0x02)
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x03)
{
Package (0x02) { "uicc-present", 1 },
Package (0x02) { "ese-present", 1 },
Package (0x02) { "reset-gpios", Package(0x04) { ^NFC1, 1, 0, 0} },
}
})
Return (SBUF) /* \_SB_.SPI1.NFC1._CRS.SBUF */
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
}
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Since
commit 10cf4899f8 ("gpiolib: tighten up ACPI legacy gpio lookups")
If _DSD properties are available in an ACPI node, we are not
allowed to fallback to _CRS data to retrieve gpio properties.
This was causing us to fail if uicc-present and/or ese-present
are defined.
To be consistent with devicetree change ST_NCI_GPIO_NAME_RESET
content to reset so that acpi_find_gpio in drivers/gpio/gpiolib.c
will look for reset-gpios. In the mean time the ACPI table needs
to be fixed as follow:
Device (NFC1)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "SMO2101") // _HID: Hardware ID
Name (_CID, "SMO2101") // _CID: Compatible ID
Name (_DDN, "SMO NFC") // _DDN: DOS Device Name
Name (_UID, One) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (SBUF, ResourceTemplate ()
{
I2cSerialBus (0x0008, ControllerInitiated, 400000,
AddressingMode7Bit, "\\_SB.I2C7",
0x00, ResourceConsumer, ,)
GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPO2", 0x00, ResourceConsumer, ,)
{ // Pin list
0x0001
}
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.GPO2", 0x00, ResourceConsumer, ,)
{ // Pin list
0x0002,
}
})
Name (_DSD, Package (0x02)
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x03)
{
Package (0x02) { "uicc-present", 1 },
Package (0x02) { "ese-present", 1 },
Package (0x02) { "reset-gpios", Package(0x04) { ^NFC1, 1, 0, 0} },
}
})
Return (SBUF) /* \_SB_.I2C7.NFC1._CRS.SBUF */
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
}
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Fix static checker warning:
drivers/nfc/st21nfca/i2c.c:530 st21nfca_hci_i2c_acpi_request_resources()
error: 'gpiod_ena' dereferencing possible ERR_PTR()
Fix so that if no enable gpio can be retrieved an -ENODEV is returned.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: dfa8070d7f ("nfc: st21nfca: Add support for acpi probing for i2c device.")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This adds the I2C phy interface for the pn533 driver.
This way the driver can be used to interact with I2C
connected pn532 devices.
Signed-off-by: Michael Thalmeier <michael.thalmeier@hale.at>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The driver now has all core stuff isolated in one file, and all
the hardware link specifics in another. Writing a pn533 driver
on top of another hardware link is now just a matter of adding a
new file for that new hardware specifics.
The first user of this separation will be the i2c based pn532
driver that reuses pn533 core implementation on top of an i2c
layer.
Signed-off-by: Michael Thalmeier <michael.thalmeier@hale.at>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
A deadlock can occur when the NFC raw socket is closed while
the driver is processing a command.
Following is the call graph of the affected situation:
send data via raw_sock:
-------------
rawsock_tx_work
sock_hold => socket refcnt++
nfc_data_exchange => cb = rawsock_data_exchange_complete
ops->im_transceive = pn533_transceive => arg->cb = db
= rawsock_data_exchange_complete
pn533_send_data_async => cb = pn533_data_exchange_complete
__pn533_send_async => cmd->complete_cb = cb
= pn533_data_exchange_complete
if_ops->send_frame_async
response:
--------
pn533_recv_response
queue_work(priv->wq, &priv->cmd_complete_work)
pn533_wq_cmd_complete
pn533_send_async_complete
cmd->complete_cb() = pn533_data_exchange_complete()
arg->cb() = rawsock_data_exchange_complete()
sock_put => socket refcnt-- => If the corresponding
socket gets closed in the meantime socket
will be destructed
sk_free
__sk_free
sk->sk_destruct = rawsock_destruct
nfc_deactivate_target
ops->deactivate_target = pn533_deactivate_target
pn533_send_cmd_sync
pn533_send_cmd_async
__pn533_send_async
list_add_tail(&cmd->queue,&dev->cmd_queue)
=> add to command list because
a command is currently
processed
wait_for_completion
=> the workqueue thread waits
here because it is the one
processing the commands
=> deadlock
To fix the deadlock pn533_deactivate_target is changed to
issue the PN533_CMD_IN_RELEASE command in async mode. This
way nothing blocks and the release command is executed after
the current command.
Signed-off-by: Michael Thalmeier <michael.thalmeier@hale.at>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Currently it is not possible to only poll for passive targets
with the pn533 driver. To change this ATR_REQ is only sent when
NFC_PROTO_NFC_DEP is explicitly requested in poll_protocols.
As most implementations (e.g. neard) poll for all protocols
that are reported to be supported by the adapter, this should
not have much of an effect on current implementations.
Signed-off-by: Michael Thalmeier <michael.thalmeier@hale.at>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
