From: Arnd Bergmann <arnd@arndb.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Waldemar.Rymarkiewicz@tieto.com, sameo@linux.intel.com,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
hthebaud@insidefr.com, matti.j.aaltonen@nokia.com
Subject: Re: [PATCH] NFC: Driver for Inside Secure MicroRead NFC chip
Date: Tue, 29 Mar 2011 14:04:38 +0200 [thread overview]
Message-ID: <201103291404.39023.arnd@arndb.de> (raw)
In-Reply-To: <20110329125931.21a69776@lxorguk.ukuu.org.uk>
On Tuesday 29 March 2011, Alan Cox wrote:
> > The difference between the two is where you keep the common
> > NFC logic:
>
> I think I'd disagree on that
> >
> > If you have a character device, it will be like a serial port
> > connecting to a modem. Any higher-level protocols live in the
> > user space and are limited to a single application then, which
> > is required to have appropriate priviledges to open the device.
>
> A socket is just an API just as a file, you can put the stack in either
> place in either case.
Fair enough. Obviously the character device that we've been talking
about here does not include the stack, but that would be another option.
As you say, using a socket with a dumb interface is also possible,
but that sounds to me like a combination of all the disadvantages.
> > character device is its simplicity, so that would be preferred
> > if you only expect a very small set of possible applications
> > for this.
>
> NFC is not particularly performance dependant so having a lot of the
> stack in a daemon isn't really going to hurt anything too much on a
> client embedded device/phone.
>
> The bigger question is probably what it needs to look like the other end
> - ie the server side embedded devices doing transactions.
I was under the impression that NFC was peer-to-peer, so the driver
would already be handling both sides potentially.
Arnd
next prev parent reply other threads:[~2011-03-29 12:04 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-18 10:40 [PATCH] NFC: Driver for Inside Secure MicroRead NFC chip Waldemar Rymarkiewicz
2011-03-18 10:40 ` Waldemar Rymarkiewicz
2011-03-18 11:03 ` Alan Cox
2011-03-18 15:00 ` Waldemar.Rymarkiewicz
2011-03-18 15:05 ` Arnd Bergmann
2011-03-18 15:12 ` Alan Cox
2011-03-18 15:15 ` Waldemar.Rymarkiewicz
2011-03-18 11:49 ` Wolfram Sang
2011-03-18 15:08 ` Waldemar.Rymarkiewicz
2011-03-18 15:31 ` Mark Brown
2011-03-18 16:43 ` Waldemar.Rymarkiewicz
2011-03-18 12:19 ` Arnd Bergmann
2011-03-18 12:51 ` Mark Brown
2011-03-18 14:20 ` Arnd Bergmann
2011-03-25 14:26 ` Samuel Ortiz
2011-03-29 8:00 ` Waldemar.Rymarkiewicz
2011-03-29 11:05 ` Arnd Bergmann
2011-03-29 11:59 ` Alan Cox
2011-03-29 12:04 ` Arnd Bergmann [this message]
2011-03-29 12:23 ` Alan Cox
2011-03-29 13:22 ` Arnd Bergmann
2011-03-31 14:16 ` Samuel Ortiz
2011-03-31 14:42 ` Waldemar.Rymarkiewicz
2011-03-31 14:49 ` Arnd Bergmann
2011-03-31 15:09 ` Samuel Ortiz
2011-03-31 15:24 ` Waldemar.Rymarkiewicz
2011-03-31 15:30 ` Samuel Ortiz
2011-04-01 18:19 ` Aloisio Almeida
2011-04-01 19:43 ` Arnd Bergmann
2011-06-06 20:22 ` Pavan Savoy
2011-06-06 20:30 ` Pavan Savoy
2011-06-06 20:46 ` Aloisio Almeida
2011-06-06 20:50 ` Samuel Ortiz
2011-03-18 15:50 ` Randy Dunlap
2011-03-18 15:57 ` Waldemar.Rymarkiewicz
-- strict thread matches above, loose matches on Subject: below --
2011-03-10 14:20 Waldemar Rymarkiewicz
2011-03-10 13:52 ` Arnd Bergmann
2011-03-10 14:45 ` Waldemar.Rymarkiewicz
2011-03-10 16:20 ` Arnd Bergmann
2011-03-14 14:59 ` Waldemar.Rymarkiewicz
2011-03-14 15:34 ` Arnd Bergmann
2011-03-14 15:45 ` Waldemar.Rymarkiewicz
2011-03-14 16:00 ` Arnd Bergmann
2011-03-14 16:15 ` Waldemar.Rymarkiewicz
2011-03-14 17:01 ` Arnd Bergmann
2011-03-15 8:37 ` Waldemar.Rymarkiewicz
2011-03-15 9:06 ` Arnd Bergmann
2011-03-17 12:58 ` Waldemar.Rymarkiewicz
2011-03-17 13:07 ` Arnd Bergmann
2011-03-17 13:38 ` Waldemar.Rymarkiewicz
2011-03-17 13:54 ` Arnd Bergmann
2011-03-17 13:58 ` Waldemar.Rymarkiewicz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201103291404.39023.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=Waldemar.Rymarkiewicz@tieto.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hthebaud@insidefr.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matti.j.aaltonen@nokia.com \
--cc=sameo@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox