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:	Tue, 9 Apr 2013 15:46:21 +0200
From:	Samuel Ortiz <sameo@...ux.intel.com>
To:	"Winkler, Tomas" <tomas.winkler@...el.com>,
	Greg KH <gregkh@...uxfoundation.org>
Cc:	"arnd@...db.de" <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [char-misc-next 0/3 V6] Support NFC Device on MEI CL Bus

Hi Greg, Tomas,

On Tue, Apr 09, 2013 at 01:12:48PM +0000, Winkler, Tomas wrote:
> > 
> > On Tue, Apr 09, 2013 at 02:41:32AM +0300, Tomas Winkler wrote:
> > > v5 -> v6
> > >  1. include/linux/uapi/mei/nfc.h - provides API also for pure
> > >     user space implementation as found under Android.
> > >  2. Removed INTEL_MEI_BUS_NFC Kconfig option.
> > >     The NFC info client is disconnected as soon as we
> > >     get the FW info and the regular client is connected only when
> > >     mei_cl_enable_device() is explicitly called from an nfc driver.
> > >     The mei cl bus now doesn't connect NFC  exclusively.
> > >  3. Added pn544 to the possibly detected NFC chipsets.
> > >
> > > Depends on:
> > > 	mei: bus: Add device enabling and disabling API
> > 
> > If this is a nfc device, why isn't it using the nfc_register_device() and
> > nfc_unregister_device() calls?  Shouldn't you be using the in-kernel nfc api
> > we already have?
The mei/nfc.c code adds a physical device to the MEI bus, the in kernel NFC
APIs will be called by the NFC driver (drivers/nfc/) itself, once probed. The
mei/nfc.c code is not an NFC driver, it is an MEI specific layer for properly
detecting the right NFC chipsets behind the ME and abstracting the MEI secific
commands for this chipset.

This code is needed because the only think that the ME tells us at boot
time is that there is an NFC related UUID there. It can be any NFC chipset
(Although right now the firmware will only support the microread and pn544
ones) and to know exactly which one it is we need to send a few commands to
the ME firmware. Once that's done, we add a device to the MEI bus with the
proper name ("pn544" or "microread"). The actual driver living under
drivers/nfc/ will be probed and then register itself against the NFC
subsystem (through the NFC in-kernel APIs).
By doing so we keep the ME related operations under drivers/misc/mei while
drivers/nfc/ only deals with NFC related stuff.

I hope this clears things up.  If it does, we can add a similar explanation to
the first patch of this patchset.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
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