<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/net/nfc/netlink.c, branch v4.3</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>nfc: netlink: Add capability to reply to vendor_cmd with data</title>
<updated>2015-08-20T20:00:11+00:00</updated>
<author>
<name>Christophe Ricard</name>
<email>christophe.ricard@gmail.com</email>
</author>
<published>2015-08-19T19:26:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=29e76924cf087bc6a9114a9244828fd13ae959bb'/>
<id>29e76924cf087bc6a9114a9244828fd13ae959bb</id>
<content type='text'>
A proprietary vendor command may send back useful data to the user
application.

For example, the field level applied on the NFC router antenna.

Still based on net/wireless/nl80211.c implementation,
add nfc_vendor_cmd_alloc_reply_skb and nfc_vendor_cmd_reply in
order to send back over netlink data generated by a proprietary
command.

Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A proprietary vendor command may send back useful data to the user
application.

For example, the field level applied on the NFC router antenna.

Still based on net/wireless/nl80211.c implementation,
add nfc_vendor_cmd_alloc_reply_skb and nfc_vendor_cmd_reply in
order to send back over netlink data generated by a proprietary
command.

Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nfc: netlink: Warning fix</title>
<updated>2015-08-17T08:45:19+00:00</updated>
<author>
<name>Christophe Ricard</name>
<email>christophe.ricard@gmail.com</email>
</author>
<published>2015-08-17T06:33:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=adca3c38d807b341a965d0aba8721d0784d8471b'/>
<id>adca3c38d807b341a965d0aba8721d0784d8471b</id>
<content type='text'>
When NFC_ATTR_VENDOR_DATA is not set, data_len is 0 and data is NULL.

Fixes the following warning:

net/nfc/netlink.c:1536:3: warning: 'data' may be used uninitialized
+in this function [-Wmaybe-uninitialized]
      return cmd-&gt;doit(dev, data, data_len);

Cc: stable@vger.kernel.org
Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When NFC_ATTR_VENDOR_DATA is not set, data_len is 0 and data is NULL.

Fixes the following warning:

net/nfc/netlink.c:1536:3: warning: 'data' may be used uninitialized
+in this function [-Wmaybe-uninitialized]
      return cmd-&gt;doit(dev, data, data_len);

Cc: stable@vger.kernel.org
Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nfc: netlink: Add check on NFC_ATTR_VENDOR_DATA</title>
<updated>2015-08-16T23:36:17+00:00</updated>
<author>
<name>Christophe Ricard</name>
<email>christophe.ricard@gmail.com</email>
</author>
<published>2015-08-14T20:33:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=fe202fe95564023223ce1910c9e352f391abb1d5'/>
<id>fe202fe95564023223ce1910c9e352f391abb1d5</id>
<content type='text'>
NFC_ATTR_VENDOR_DATA is an optional vendor_cmd argument.
The current code was potentially using a non existing argument
leading to potential catastrophic results.

Cc: stable@vger.kernel.org
Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
NFC_ATTR_VENDOR_DATA is an optional vendor_cmd argument.
The current code was potentially using a non existing argument
leading to potential catastrophic results.

Cc: stable@vger.kernel.org
Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>NFC: netlink: Implement vendor command support</title>
<updated>2015-06-08T23:21:35+00:00</updated>
<author>
<name>Samuel Ortiz</name>
<email>sameo@linux.intel.com</email>
</author>
<published>2014-10-14T00:19:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=9e58095f9660f88d6a2febe87d5073a6b2e9c399'/>
<id>9e58095f9660f88d6a2febe87d5073a6b2e9c399</id>
<content type='text'>
Vendor commands are passed from userspace through the
NFC_CMD_VENDOR netlink command, allowing driver and hardware
specific operations implementations like for example RF tuning
or production line calibration.

Drivers will associate a set of vendor commands to a vendor
id, which could typically be an OUI. The netlink kernel
implementation will try to match the received vendor id
and sub command attributes with the registered ones. When
such match is found, the driver defined sub command routine
is called.

Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Vendor commands are passed from userspace through the
NFC_CMD_VENDOR netlink command, allowing driver and hardware
specific operations implementations like for example RF tuning
or production line calibration.

Drivers will associate a set of vendor commands to a vendor
id, which could typically be an OUI. The netlink kernel
implementation will try to match the received vendor id
and sub command attributes with the registered ones. When
such match is found, the driver defined sub command routine
is called.

Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nfc: Fix portid type in urelease_work</title>
<updated>2015-04-13T20:35:16+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2015-04-12T22:52:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=65bc4f936e6f1c7de59938e832701faa903d2d45'/>
<id>65bc4f936e6f1c7de59938e832701faa903d2d45</id>
<content type='text'>
portid is an unsigned integer. Fix urelease_work to
match all other portid user in the kernel.

Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
portid is an unsigned integer. Fix urelease_work to
match all other portid user in the kernel.

Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>NFC: Forward NFC_EVT_TRANSACTION to user space</title>
<updated>2015-02-02T20:50:40+00:00</updated>
<author>
<name>Christophe Ricard</name>
<email>christophe.ricard@gmail.com</email>
</author>
<published>2015-02-01T21:26:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=447b27c4f29b510b98e99395120d635f009ed563'/>
<id>447b27c4f29b510b98e99395120d635f009ed563</id>
<content type='text'>
NFC_EVT_TRANSACTION is sent through netlink in order for a
specific application running on a secure element to notify
userspace of an event. Typically the secure element application
counterpart on the host could interpret that event and act
upon it.

Forwarded information contains:
- SE host generating the event
- Application IDentifier doing the operation
- Applications parameters

Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
NFC_EVT_TRANSACTION is sent through netlink in order for a
specific application running on a secure element to notify
userspace of an event. Typically the secure element application
counterpart on the host could interpret that event and act
upon it.

Forwarded information contains:
- SE host generating the event
- Application IDentifier doing the operation
- Applications parameters

Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>netlink: make nlmsg_end() and genlmsg_end() void</title>
<updated>2015-01-18T06:03:45+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-01-16T21:09:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=053c095a82cf773075e83d7233b5cc19a1f73ece'/>
<id>053c095a82cf773075e83d7233b5cc19a1f73ece</id>
<content type='text'>
Contrary to common expectations for an "int" return, these functions
return only a positive value -- if used correctly they cannot even
return 0 because the message header will necessarily be in the skb.

This makes the very common pattern of

  if (genlmsg_end(...) &lt; 0) { ... }

be a whole bunch of dead code. Many places also simply do

  return nlmsg_end(...);

and the caller is expected to deal with it.

This also commonly (at least for me) causes errors, because it is very
common to write

  if (my_function(...))
    /* error condition */

and if my_function() does "return nlmsg_end()" this is of course wrong.

Additionally, there's not a single place in the kernel that actually
needs the message length returned, and if anyone needs it later then
it'll be very easy to just use skb-&gt;len there.

Remove this, and make the functions void. This removes a bunch of dead
code as described above. The patch adds lines because I did

-	return nlmsg_end(...);
+	nlmsg_end(...);
+	return 0;

I could have preserved all the function's return values by returning
skb-&gt;len, but instead I've audited all the places calling the affected
functions and found that none cared. A few places actually compared
the return value with &lt;= 0 in dump functionality, but that could just
be changed to &lt; 0 with no change in behaviour, so I opted for the more
efficient version.

One instance of the error I've made numerous times now is also present
in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't
check for &lt;0 or &lt;=0 and thus broke out of the loop every single time.
I've preserved this since it will (I think) have caused the messages to
userspace to be formatted differently with just a single message for
every SKB returned to userspace. It's possible that this isn't needed
for the tools that actually use this, but I don't even know what they
are so couldn't test that changing this behaviour would be acceptable.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Contrary to common expectations for an "int" return, these functions
return only a positive value -- if used correctly they cannot even
return 0 because the message header will necessarily be in the skb.

This makes the very common pattern of

  if (genlmsg_end(...) &lt; 0) { ... }

be a whole bunch of dead code. Many places also simply do

  return nlmsg_end(...);

and the caller is expected to deal with it.

This also commonly (at least for me) causes errors, because it is very
common to write

  if (my_function(...))
    /* error condition */

and if my_function() does "return nlmsg_end()" this is of course wrong.

Additionally, there's not a single place in the kernel that actually
needs the message length returned, and if anyone needs it later then
it'll be very easy to just use skb-&gt;len there.

Remove this, and make the functions void. This removes a bunch of dead
code as described above. The patch adds lines because I did

-	return nlmsg_end(...);
+	nlmsg_end(...);
+	return 0;

I could have preserved all the function's return values by returning
skb-&gt;len, but instead I've audited all the places calling the affected
functions and found that none cared. A few places actually compared
the return value with &lt;= 0 in dump functionality, but that could just
be changed to &lt; 0 with no change in behaviour, so I opted for the more
efficient version.

One instance of the error I've made numerous times now is also present
in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't
check for &lt;0 or &lt;=0 and thus broke out of the loop every single time.
I've preserved this since it will (I think) have caused the messages to
userspace to be formatted differently with just a single message for
every SKB returned to userspace. It's possible that this isn't needed
for the tools that actually use this, but I don't even know what they
are so couldn't test that changing this behaviour would be acceptable.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>NFC: Add se_io NFC operand</title>
<updated>2014-12-02T21:47:56+00:00</updated>
<author>
<name>Christophe Ricard</name>
<email>christophe.ricard@gmail.com</email>
</author>
<published>2014-12-02T20:27:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=cd96db6fd0ac1c352e386fb2c632c455bf501e1f'/>
<id>cd96db6fd0ac1c352e386fb2c632c455bf501e1f</id>
<content type='text'>
se_io allows to send apdu over the CLF to the embedded
Secure Element.

Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
se_io allows to send apdu over the CLF to the embedded
Secure Element.

Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>NFC: netlink: Add new netlink command NFC_CMD_ACTIVATE_TARGET</title>
<updated>2014-12-02T21:47:37+00:00</updated>
<author>
<name>Christophe Ricard</name>
<email>christophe.ricard@gmail.com</email>
</author>
<published>2014-12-02T20:27:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=3682f49f32051765ed6eb77fc882f0458f7d44c3'/>
<id>3682f49f32051765ed6eb77fc882f0458f7d44c3</id>
<content type='text'>
Some tag might get deactivated after some read or write tentative.
This may happen for example with Mifare Ultralight C tag when trying
to read the last 4 blocks (starting block 0x2c) configured as write
only.
NFC_CMD_ACTIVATE_TARGET will try to reselect the tag in order to
detect if it got remove from the field or if it is still present.

Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some tag might get deactivated after some read or write tentative.
This may happen for example with Mifare Ultralight C tag when trying
to read the last 4 blocks (starting block 0x2c) configured as write
only.
NFC_CMD_ACTIVATE_TARGET will try to reselect the tag in order to
detect if it got remove from the field or if it is still present.

Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>NFC: Add netlink support for ISO/IEC 15693</title>
<updated>2014-02-16T22:49:53+00:00</updated>
<author>
<name>Mark A. Greer</name>
<email>mgreer@animalcreek.com</email>
</author>
<published>2014-01-15T00:52:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=f5f6872ed2d9a33f99013f6bad734b7f0684da23'/>
<id>f5f6872ed2d9a33f99013f6bad734b7f0684da23</id>
<content type='text'>
Add ISO/IEC 15693 support by having netlink push the
1-byte DSFID and 8-byte UID tag information upstream.

Signed-off-by: Mark A. Greer &lt;mgreer@animalcreek.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add ISO/IEC 15693 support by having netlink push the
1-byte DSFID and 8-byte UID tag information upstream.

Signed-off-by: Mark A. Greer &lt;mgreer@animalcreek.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
