lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 23 Aug 2013 11:28:47 +0200
From:	Lars Poeschel <poeschel@...onage.de>
To:	"Rymarkiewicz, WaldemarX" <waldemarx.rymarkiewicz@...el.com>
Cc:	Lars Poeschel <larsi@....tu-dresden.de>,
	"lauro.venancio@...nbossa.org" <lauro.venancio@...nbossa.org>,
	"aloisio.almeida@...nbossa.org" <aloisio.almeida@...nbossa.org>,
	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"jslaby@...e.cz" <jslaby@...e.cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"linux-nfc@...ts.01.org" <linux-nfc@...ts.01.org>
Subject: Re: [linux-nfc] [PATCH RFC] nfc: add a driver for pn532 connected on uart

On Friday 23 August 2013 at 07:23:00, Rymarkiewicz, WaldemarX wrote:
> Hi  Lars,
> 
> >This adds a driver for the nxp pn532 nfc chip.
> >It is not meant for merging. Instead it is meant to show that some
> >progress has been made and what the current state is and to help
> >testing.
> >Although I can do some basic things with this driver I expect it to
> >contain lots of bugs. Be aware!
> >This driver is heavily based on the pn533 driver and duplicates much
> >code. This has do be factored out some time.
> 
> I'm not sure if this is expected approach adding new drivers. You
> duplicates most of pn533 code which is not good.

Yes, I know that and I explicitly mentioned that. I had to get this chip 
working somehow and I had to begin somewhere. The pn533 driver is really 
very hard to understand with it's massive use of nested callbacks, 
workqueues and usb urbs. So I took the approach to try to understand what 
happens while modifying and would then later factor out what both drivers 
have in common. The other way is understanding the code first and then 
decide what would be needed for both chips, factor that out and then write 
the pn532 uart specific stuff. And this uart stuff is a pain itself in 
linux. This way seemed much harder to me, especially as I have no pn533 
device to test which things will break.

> Also, note that pn533 and pn532  are pretty the same chips (with small
> differences) and it would be quite natural to support both with one
> driver. Pn533 already reads chip version on init, so at this point you
> already know with which chip you are dealing with.
> 
> I suggest to separate transport layer from the core in pn533 and add
> support for uart and usb separately. This is exactly what I've planned
> while changing pn533 to support acr122 device.

Yes, I agree with you this should be done. I'll expect it to be challenging 
but based on my previous work this could be doable. I'll look into that in 
my next free timeslot. I'll not be able to do that in the next two months. 
Sorry.

Thank you for your comments,
Lars
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ