From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754006AbcEDPSi (ORCPT ); Wed, 4 May 2016 11:18:38 -0400 Received: from 7of9.schinagl.nl ([88.159.158.68]:48848 "EHLO 7of9.schinagl.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753720AbcEDPSg (ORCPT ); Wed, 4 May 2016 11:18:36 -0400 Subject: Re: [PATCH 00/11] NFC: pn533: bug fixes and improvements To: Michael Thalmeier , Samuel Ortiz References: <1461249839-16962-1-git-send-email-michael.thalmeier@hale.at> <57225411.1060304@schinagl.nl> Cc: Lauro Ramos Venancio , Aloisio Almeida Jr , linux-kernel@vger.kernel.org, linux-nfc@ml01.01.org, michael@thalmeier.at Newsgroups: gmane.linux.kernel From: Olliver Schinagl Message-ID: <572A12C0.40804@schinagl.nl> Date: Wed, 4 May 2016 17:18:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <57225411.1060304@schinagl.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Michael, On 28-04-16 20:18, Olliver Schinagl wrote: > Hi Michael, > > I know i'm a little late to the party, but why did you not name the > directory/driver pn53x? I don't think we should debate wether a 533 is a > 532 with a USB added, or wether a 532 is a 533 with the USB stripped, I > was just curious. As for the pn533-i2c, in the KConfig, I'd probably > recommend naming it pn532 at the least though, since there is no variant > other then USB for the 533? > > Further more, I think it would be wise to add some documentation and nfc > bindings examples. > > I'm using it as a subnode of an i2c node as such: > > &i2c2 { > pinctrl-names = "default"; > pinctrl-0 = <&i2c2_pins_a>; > status = "okay"; > > pn532: pn53x@48 { > compatible = "nxp,pn532-i2c"; > reg = <0x48>; > }; > }; > > But not sure if this is correct at all (I haven't gotten it to work yet, > partly due to a burnt level shifter). For example, I'm not sure what > other properties are needed. I think that this is all fine, it should be 0x24 instead of 0x48 if it matters at all (hardcoded in the driver?) but my initial problem was that i was loading pn533 and not pn533_i2c. The driver seems to like to use an interrupt (one of the optional pins on the chip (nice for the documentation :)) other then the i2c interrupt I assume? After the warning that we do not have an interrupt, we call pn533_register, which then just sits there waiting forever. I'll add more printk's into the pn533 driver to find out why, but if you have an idea and can save me some work, that'd be great! Olliver > > Olliver > > On 21-04-16 16:43, Michael Thalmeier wrote: >> Hello Samuel, >> >> This patchset fixes some major bugs in the pn533 drivers (usb and i2c) >> and >> improves performance of the PN532 chip by increasing its clock speed. >> >> Best Regards >> Michael >> >> Michael Thalmeier (11): >> NFC: pn533: i2c: free irq on driver remove >> NFC: pn533: fix order of initialization >> NFC: pn533: i2c: do not call pn533_recv_frame with aborted commands >> NFC: pn533: reset poll modulation list before calling >> nfc_targets_found >> NFC: pn533: handle interrupted commands in pn533_recv_frame >> NFC: pn533: usb: fix errors when poll is stopped >> NFC: pn533: improve cmd queue handling >> NFC: pn533: reduce output when stopping poll >> NFC: pn533: use nfc_alloc_recv_skb for skb allocation >> NFC: pn533: set cmd status when not set >> nfc: pn533: increase clock frequency for PN532 >> >> drivers/nfc/pn533/i2c.c | 20 ++++-- >> drivers/nfc/pn533/pn533.c | 154 >> +++++++++++++++++++++++++++++++++++++--------- >> drivers/nfc/pn533/pn533.h | 5 +- >> drivers/nfc/pn533/usb.c | 15 +++-- >> 4 files changed, 153 insertions(+), 41 deletions(-) >> > >