linux-kernel - Re: [PATCH] NFC: Driver for Inside Secure MicroRead NFC chip

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:	Thu, 31 Mar 2011 16:49:21 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Waldemar.Rymarkiewicz@...to.com
Cc:	sameo@...ux.intel.com, linux-i2c@...r.kernel.org,
	linux-kernel@...r.kernel.org, hthebaud@...idefr.com,
	matti.j.aaltonen@...ia.com, alan@...rguk.ukuu.org.uk,
	Sebastian.Chlad@...to.com
Subject: Re: [PATCH] NFC: Driver for Inside Secure MicroRead NFC chip

On Thursday 31 March 2011, Waldemar.Rymarkiewicz@...to.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 NFC HCI layer in kernel land and could 
> >potentially simplify the existing NFC stacks.
> 
> Shouldn't be better to add a new AF_NFC sock family and then
> register new LLCP and HCI protocols?

That depends on what the HCI protocol really looks like, e.g.
is it's related to the LLCP data at all or not.

Another option might be to control the HCI over setsockopts,
but the netlink socket sounds more flexible for this.

	Arnd
--
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/