Skip to content
Snippets Groups Projects
  1. Nov 16, 2012
  2. Nov 13, 2012
  3. Oct 30, 2012
  4. Oct 25, 2012
  5. Oct 24, 2012
  6. Oct 23, 2012
  7. Oct 21, 2012
  8. Oct 17, 2012
  9. Oct 16, 2012
  10. Oct 15, 2012
  11. Oct 14, 2012
  12. Oct 11, 2012
  13. Oct 10, 2012
  14. Oct 09, 2012
  15. Oct 08, 2012
    • Marek Vasut's avatar
      MXS: Implement DMA support into mxs-i2c · 62885f59
      Marek Vasut authored
      
      This patch implements DMA support into mxs-i2c. DMA transfers are now enabled
      via DT. The DMA operation is enabled by default.
      
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Tested-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      
      [wsa: rebased to 3.6-rc7]
      
      Signed-off-by: default avatarWolfram Sang <w.sang@pengutronix.de>
      62885f59
    • David Howells's avatar
      KEYS: Document asymmetric key type · 9a83b465
      David Howells authored
      
      In-source documentation for the asymmetric key type.  This will be located in:
      
      	Documentation/crypto/asymmetric-keys.txt
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      9a83b465
    • David Howells's avatar
      KEYS: Add payload preparsing opportunity prior to key instantiate or update · cf7f601c
      David Howells authored
      
      Give the key type the opportunity to preparse the payload prior to the
      instantiation and update routines being called.  This is done with the
      provision of two new key type operations:
      
      	int (*preparse)(struct key_preparsed_payload *prep);
      	void (*free_preparse)(struct key_preparsed_payload *prep);
      
      If the first operation is present, then it is called before key creation (in
      the add/update case) or before the key semaphore is taken (in the update and
      instantiate cases).  The second operation is called to clean up if the first
      was called.
      
      preparse() is given the opportunity to fill in the following structure:
      
      	struct key_preparsed_payload {
      		char		*description;
      		void		*type_data[2];
      		void		*payload;
      		const void	*data;
      		size_t		datalen;
      		size_t		quotalen;
      	};
      
      Before the preparser is called, the first three fields will have been cleared,
      the payload pointer and size will be stored in data and datalen and the default
      quota size from the key_type struct will be stored into quotalen.
      
      The preparser may parse the payload in any way it likes and may store data in
      the type_data[] and payload fields for use by the instantiate() and update()
      ops.
      
      The preparser may also propose a description for the key by attaching it as a
      string to the description field.  This can be used by passing a NULL or ""
      description to the add_key() system call or the key_create_or_update()
      function.  This cannot work with request_key() as that required the description
      to tell the upcall about the key to be created.
      
      This, for example permits keys that store PGP public keys to generate their own
      name from the user ID and public key fingerprint in the key.
      
      The instantiate() and update() operations are then modified to look like this:
      
      	int (*instantiate)(struct key *key, struct key_preparsed_payload *prep);
      	int (*update)(struct key *key, struct key_preparsed_payload *prep);
      
      and the new payload data is passed in *prep, whether or not it was preparsed.
      
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      cf7f601c
  16. Oct 07, 2012
Loading