linux-kernel - Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines

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] [day] [month] [year] [list]

Message-ID: <1684430.yK4oBgpgAE@wuerfel>
Date:	Mon, 11 Feb 2013 17:12:48 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Samuel Ortiz <sameo@...ux.intel.com>
Cc:	Tomas Winkler <tomas.winkler@...el.com>,
	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org
Subject: Re: [char-misc-next 03/11] mei: bus: Initial implementation for I/O routines

On Monday 11 February 2013 16:48:12 Samuel Ortiz wrote:
> 
> > If so, how do you know which transport to use?
> Through the mei_bus_client ops. Device drivers get a mei_bus_client pointer
> from their probe routine and the ops pointers there (If any) are set by
> whoever creates the device. In the NFC case mei/nfc.c does that and implements
> the NFC specific transport code for this technology. mei/nfc.c is also the
> part of the code that actually adds the device to the bus.

Ok.

> So when a device driver wants e.g. to send its payload through the MEI bus, it
> calls mei_bus_send() which takes the device driver mei_bus client pointer as
> its first argument.
> Then the payload may go through mei_bus_client->send() first which will eventually
> physically sent the newly built frame through mei_send(). Some ME blocks don't require any
> additional transport layer and in that case the device driver payload will go
> straight to mei_send() since the mei_bus_client ops will be NULL.
> 
> Does that make more sense now ?

Yes, so it's not actually as complicated as I thought, because
the operations are already known by the bus driver (in the
normal sense of that word, meaning the driver that creates
the device not the one driving it) at the time when the device is
created.

In that case, please ignore my original comment and put the
struct mei_bus_ops (mei_transport_ops?) back, ideally as a
"const" member of the struct mei_bus_device (to be called
mei_device then), so you can declare the structure statically
and constant in the driver that has the functions.

	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/