Hi, >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.
I understand. It took me some time to understand this too. Now, it's even harder after adding protocol ops, but still is pretty well layered. > 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. Be sure there will be pitfalls separating transport. I've already experienced some of them adding support for acr122. >> I'll look into that in my next free timeslot. I'll not be able to do that in >> the next two months. >>Sorry. No worries. I know this pain :) Thanks, /Waldek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
