On Thu, Mar 31, 2011 at 9:30 AM, Samuel Ortiz sa...@linux.intel.com wrote:
On Thu, Mar 31, 2011 at 06:24:50PM +0300, waldemar.rymarkiew...@tieto.com
wrote:
Hi Samuel,
That's the Bluetooth approach, and it works just fine as well.
However, the netlink option for sending commands and
On Mon, Jun 6, 2011 at 3:22 PM, Pavan Savoy pavan_sa...@sify.com wrote:
On Thu, Mar 31, 2011 at 9:30 AM, Samuel Ortiz sa...@linux.intel.com wrote:
On Thu, Mar 31, 2011 at 06:24:50PM +0300, waldemar.rymarkiew...@tieto.com
wrote:
Hi Samuel,
That's the Bluetooth approach, and it works just
On Mon, Jun 6, 2011 at 5:30 PM, Pavan Savoy pavan_sa...@sify.com wrote:
Yes apparently I did miss a whole of patches in the series.
So, for anyone who is interested on the list - this is the proposed
architecture,
Hi Pavan,
On Mon, Jun 06, 2011 at 03:22:01PM -0500, Pavan Savoy wrote:
On Thu, Mar 31, 2011 at 9:30 AM, Samuel Ortiz sa...@linux.intel.com wrote:
On Thu, Mar 31, 2011 at 06:24:50PM +0300, waldemar.rymarkiew...@tieto.com
wrote:
Hi Samuel,
That's the Bluetooth approach, and it works
Hi all,
On Thu, Mar 31, 2011 at 12:30 PM, Samuel Ortiz sa...@linux.intel.com wrote:
On Thu, Mar 31, 2011 at 06:24:50PM +0300, waldemar.rymarkiew...@tieto.com
wrote:
Hi Samuel,
That's the Bluetooth approach, and it works just fine as well.
However, the netlink option for sending commands
On Friday 01 April 2011 20:19:30 Aloisio Almeida wrote:
We are finalizing a NFC stack prototype and we decided to use generic
netlink. But during the implementation we found a disadvantage of this
approach.
While implementing data_exchange through netlink, it was not possible
to avoid
On Tue, Mar 29, 2011 at 01:05:02PM +0200, Arnd Bergmann wrote:
On Tuesday 29 March 2011, waldemar.rymarkiew...@tieto.com wrote:
Yes, NFC seems to be a good fit for a new socket family.
Especially if we ever want to have a proper NFC p2p support
from the kernel.
Sending HCI commands
My idea of an initial NFC subsystem architecture was actually
the following
one:
- A core NFC layer against which NFC drivers would register.
- A netlink socket for handling the HCI commands. That would
put a big part of the NFC HCI layer in kernel land and could
potentially simplify the
On Thursday 31 March 2011, waldemar.rymarkiew...@tieto.com wrote:
My idea of an initial NFC subsystem architecture was actually
the following
one:
- A core NFC layer against which NFC drivers would register.
- A netlink socket for handling the HCI commands. That would
put a big part of the
Hi Waldemar,
On Thu, Mar 31, 2011 at 05:42:21PM +0300, waldemar.rymarkiew...@tieto.com wrote:
My idea of an initial NFC subsystem architecture was actually
the following
one:
- A core NFC layer against which NFC drivers would register.
- A netlink socket for handling the HCI commands. That
Hi Samuel,
That's the Bluetooth approach, and it works just fine as well.
However, the netlink option for sending commands and receiving
answers to/from a subsystem sounds more appropriate, at least to me.
I haven't used netlink in practice, so just wondering why netlink. I assume,
then, it's
On Thu, Mar 31, 2011 at 06:24:50PM +0300, waldemar.rymarkiew...@tieto.com wrote:
Hi Samuel,
That's the Bluetooth approach, and it works just fine as well.
However, the netlink option for sending commands and receiving
answers to/from a subsystem sounds more appropriate, at least to me.
I
Yes, NFC seems to be a good fit for a new socket family.
Especially if we ever want to have a proper NFC p2p support
from the kernel.
Sending HCI commands should be done through a dedicated
netlink socket too.
I am currently strting to work on such solution, and I hope to
be able to come up
On Tuesday 29 March 2011, waldemar.rymarkiew...@tieto.com wrote:
Yes, NFC seems to be a good fit for a new socket family.
Especially if we ever want to have a proper NFC p2p support
from the kernel.
Sending HCI commands should be done through a dedicated
netlink socket too.
I am
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
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
I was under the impression that NFC was peer-to-peer, so the driver
would already be handling both sides potentially.
Your security requirements each side are going to be very different. A
phone or handheld device is generally single user at a time, the other
end may well be interacting with
On Tuesday 29 March 2011, Alan Cox wrote:
I was under the impression that NFC was peer-to-peer, so the driver
would already be handling both sides potentially.
Your security requirements each side are going to be very different. A
phone or handheld device is generally single user at a
On Fri, Mar 18, 2011 at 01:19:53PM +0100, Arnd Bergmann wrote:
On Friday 18 March 2011, Waldemar Rymarkiewicz wrote:
Add new driver for MicroRead NFC chip connected to i2c bus.
See Documentation/nfc/nfc-microread.txt.
As I said in my first review and Alan also pointed out now, the
most
Updated patch after Arnd's comments.
Waldek
Waldemar Rymarkiewicz (1):
NFC: Driver for Inside Secure MicroRead NFC chip
Documentation/nfc/nfc-microread.txt | 46
drivers/nfc/Kconfig | 10 +
drivers/nfc/Makefile|1 +
drivers/nfc/microread.c
Add new driver for MicroRead NFC chip connected to i2c bus.
See Documentation/nfc/nfc-microread.txt.
Signed-off-by: Waldemar Rymarkiewicz waldemar.rymarkiew...@tieto.com
---
Documentation/nfc/nfc-microread.txt | 46
drivers/nfc/Kconfig | 10 +
drivers/nfc/Makefile
On Fri, 18 Mar 2011 11:40:24 +0100
Waldemar Rymarkiewicz waldemar.rymarkiew...@tieto.com wrote:
Add new driver for MicroRead NFC chip connected to i2c bus.
Ok we now have two devices and they have differing APIs and own device
names and both from the same company. This has to stop right now and
Hi Waldemar,
On Fri, Mar 18, 2011 at 11:40:24AM +0100, Waldemar Rymarkiewicz wrote:
Add new driver for MicroRead NFC chip connected to i2c bus.
See Documentation/nfc/nfc-microread.txt.
Signed-off-by: Waldemar Rymarkiewicz waldemar.rymarkiew...@tieto.com
Besides the stuff Alan mentioned...
On Friday 18 March 2011, Mark Brown wrote:
On Fri, Mar 18, 2011 at 01:19:53PM +0100, Arnd Bergmann wrote:
On Friday 18 March 2011, Waldemar Rymarkiewicz wrote:
+
+ mutex_lock(info-rx_mutex);
+ info-irq_state = 1;
+ mutex_unlock(info-rx_mutex);
+
+
...@insidefr.com; matti.j.aalto...@nokia.com
Subject: Re: [PATCH] NFC: Driver for Inside Secure MicroRead NFC chip
On Fri, 18 Mar 2011 11:40:24 +0100
Waldemar Rymarkiewicz waldemar.rymarkiew...@tieto.com wrote:
Add new driver for MicroRead NFC chip connected to i2c bus.
Ok we now have two devices and they have
On Friday 18 March 2011, waldemar.rymarkiew...@tieto.com wrote:
Ermm nope.. why do we have do nothing ioctls ?
onfc stack requires those ones, but they are only valid for a specific test
enviroment.
This should not be a case for driver and the stack should care about it if it
needs
Wolfram,
+unsigned int irq_gpio;
+unsigned int ioh_gpio;
... you should request and setup the GPIOs before using them.
I assume the board specific code will do so.
Waldek--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to
Would it not be lighter to use atomic bit ops ?
Do you mean in order to remove rx_mutex?
mutex_lock(info-rx_mutex);
atomic_set(info-irq_state ,1);
mutex_unlock(info-rx_mutex);
looks a bit strange. I still need the rx_mutex to protect irq_state while
reading i2c.
I was thinking clear_bit/test_and_set_bit rather than atomic_t
operations.
I see, then I will for it.
Waldek--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Fri, Mar 18, 2011 at 05:08:39PM +0200, waldemar.rymarkiew...@tieto.com wrote:
Wolfram,
+ unsigned int irq_gpio;
+ unsigned int ioh_gpio;
... you should request and setup the GPIOs before using them.
I assume the board specific code will do so.
The usual pattern is that the code
On Fri, 18 Mar 2011 11:40:24 +0100 Waldemar Rymarkiewicz wrote:
Add new driver for MicroRead NFC chip connected to i2c bus.
See Documentation/nfc/nfc-microread.txt.
Signed-off-by: Waldemar Rymarkiewicz waldemar.rymarkiew...@tieto.com
---
Documentation/nfc/nfc-microread.txt | 46
Randy,
+data to be read. Then, poll() will indicate that fact to
the userspace.
+
+The application can use ioctl(MICROREAD_IOC_RESET)to reset
the hardware.
_RESET) to reset
Thanks, all are now fixed.
Waldek
--
To unsubscribe from this list:
+free_irq:
+free_irq(client-irq, info);
+free_buf:
+kfree(info-buf);
+free_info:
+kfree(info);
+
+dev_info(client-dev, Not probed.);
+return ret;
+}
When respinning, you could consider using managed devices
(devm_*); this error path could completely go then.
Well,
Hi Arnd,
Note that the microread_is_busy() logic does not protect you from
having multiple concurrent readers, because multiple threads may
share a single file descriptor.
It's just used to ensure that only one reader can open the device.
It's called only in open callback.
The mutex
On Thursday 17 March 2011, waldemar.rymarkiew...@tieto.com wrote:
Note that the microread_is_busy() logic does not protect you from
having multiple concurrent readers, because multiple threads may
share a single file descriptor.
It's just used to ensure that only one reader can open
Arnd,
An application can open the device, and then do a
pthread_create() or a fork(). In either case, you have two
concurrent threads that have access to the file pointer and
can read from it concurrently, which is inherently racy
regarding which of the processes gets the data.
In that case
On Thursday 17 March 2011, waldemar.rymarkiew...@tieto.com wrote:
This is not very different from opening the file descriptor in
multiple processes, which you prevent using your logic.
but in the case when two independent applications try to open
my device I can't let the second to access.
As I said, it's not important if you do it and it certainly
doesn't cause harm to prevent multiple open. It's just that
generally we don't care too much about this problem.
Ok, I get you.
Thanks,
Waldek--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a
It sounds strange that this will be handled in user space,
since it won't have any idea if the hardware is available again.
I've tried to find the onfc stack that talks to this device
but couldn't see it. Do you have a URL for this?
Here you are
http://sourceforge.net/projects/open-nfc/
On Tuesday 15 March 2011 09:37:04 waldemar.rymarkiew...@tieto.com wrote:
It sounds strange that this will be handled in user space,
since it won't have any idea if the hardware is available again.
I've tried to find the onfc stack that talks to this device
but couldn't see it. Do you have
Hi Arnd,
Arnd Bergmann arnd@... writes:
On Thursday 10 March 2011, Waldemar Rymarkiewicz wrote:
Add new driver for MicroRead NFC chip connected to i2c bus.
See Documentation/nfc/nfc-microread.txt.
The imlpementation looks fairly clean, no objections on that.
However, this is the
Hi Samuel,
The few currently available NFC stacks are all implementing
the NFC HCI layer in
userspace, on top of a a more or less big HAL. By at least
moving the HCI layer
down to the kernel, and having userspace talk to it through
netlink, we could
eventually get rid of those HALs.
Is HCI
Hi Waldemar,
On Tue, Mar 15, 2011 at 02:59:09PM +0200, waldemar.rymarkiew...@tieto.com wrote:
Hi Samuel,
The few currently available NFC stacks are all implementing
the NFC HCI layer in
userspace, on top of a a more or less big HAL. By at least
moving the HCI layer
down to the kernel,
Hi Arnd,
Oh, I see you simply do
ret = i2c_master_send(client, info-buf, len);
usleep_range(1000, 1);
and assume that the buffer can always be written within a
milisecond, so you just slow down output enough to never have
to worry about it, right?
A nicer solution would be
On Monday 14 March 2011, waldemar.rymarkiew...@tieto.com wrote:
Oh, I see you simply do
ret = i2c_master_send(client, info-buf, len);
usleep_range(1000, 1);
and assume that the buffer can always be written within a
milisecond, so you just slow down output enough to
Most serial drivers do this, see drivers/tty/serial for a
number of examples, or drivers/serial on older kernels.
Thanks, will check it.
That would depend on your hardware. The only important part is
that you make sure you can send out data at any time. If
i2c_master_send() causes accesses to
On Monday 14 March 2011, waldemar.rymarkiew...@tieto.com wrote:
If the usleep_range is trying to synchronize between the NFC
and the I2C chip, you must wait for a notication from the NFC
hardware that it's done.
No, it's simply there as I have been faceing i2c write error while
I do two
No, it's simply there as I have been faceing i2c write error while I
do two consecutive writes.
The second fails now and then. That's seems to be a chip issue.
I will try to investigate this issue.
Ok. It sounds like a bug in the i2c driver, you should also
take a look there. Maybe it has
On Monday 14 March 2011, waldemar.rymarkiew...@tieto.com wrote:
No, it's simply there as I have been faceing i2c write error while I
do two consecutive writes.
The second fails now and then. That's seems to be a chip issue.
I will try to investigate this issue.
Ok. It sounds like a bug
Add new driver for MicroRead NFC chip connected to i2c bus.
See Documentation/nfc/nfc-microread.txt.
Signed-off-by: Waldemar Rymarkiewicz waldemar.rymarkiew...@tieto.com
---
Documentation/nfc/nfc-microread.txt | 46
drivers/nfc/Kconfig | 10 +
drivers/nfc/Makefile
On Thursday 10 March 2011, Waldemar Rymarkiewicz wrote:
Add new driver for MicroRead NFC chip connected to i2c bus.
See Documentation/nfc/nfc-microread.txt.
The imlpementation looks fairly clean, no objections on that.
However, this is the second NFC driver (at least), and that means
it's
Hi Arnd,
However, this is the second NFC driver (at least), and that
means it's time to come up with a generic way of talking to
NFC devices from user space. We cannot allow every NFC
controller to have another set of arbitrary ioctl numbers.
What I suggest you do is to work with the
On Thursday 10 March 2011, waldemar.rymarkiew...@tieto.com wrote:
What I suggest you do is to work with the maintainers of the existing
pn544 driver (Matti and Jari) to create an NFC core library
that takes care of the character device interface and that can
be shared between the two
53 matches
Mail list logo
