mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Epshteyn, Eugene" <eugene.epshteyn@intel.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [RFC PATCH 4/4] Mobile security processor driver
Date: Wed, 28 Apr 2010 16:10:52 -0700	[thread overview]
Message-ID: <753F67ADE6F5094C9F1DBA00D1BAA8D325518252AF@orsmsx501.amr.corp.intel.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

>From 9230c90ce19747554354c9fc93b3b1c8e661894c Mon Sep 17 00:00:00 2001
From: Mark Allyn <mark.a.allyn@intel.com>
Date: Wed, 28 Apr 2010 14:41:39 -0700
Subject: RFC [PATCH 4/4] staging: sep: Update TODO

Signed-off-by: Mark A. Allyn <mark.a.allyn@intel.com>
---
  drivers/staging/sep/TODO |   36 ++++++++++++++++++++++++++++--------
  1 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/sep/TODO b/drivers/staging/sep/TODO
index ff0e931..1a8f876 100644
--- a/drivers/staging/sep/TODO
+++ b/drivers/staging/sep/TODO
@@ -1,8 +1,28 @@
-Todo's so far (from Alan Cox)
-- Fix firmware loading
-- Get firmware into firmware git tree
-- Review and tidy each algorithm function
-- Check whether it can be plugged into any of the kernel crypto API
-  interfaces
-- Do something about the magic shared memory interface and replace it
-  with something saner (in Linux terms)
+Todo's so far (from Mark Allyn)
+
+- Resolve issue wiht allowing user space software to handle
+  physical addresses
+
+- Determine device types at runtime
+
+- Ensure that all global variables be either static or be in a global structure;
+  preferably in structure
+
+- Fix formatting (it did pass checkpatch, but it's still awkward
+
+- Fix problems in singleton opens
+
+- Provide documentation on mutex, test and set, and other locking
+
+- Fix process exit logic in caller ID handler
+
+- Need to unmap memory in case of failure
+
+- Need to document errors
+
+- Fix the way the device is set up; let the probe do the stuff such as
+  registering the device with the driver
+
+- Use cpu_to_le or cpu_to_bt instead of SEP_CHANGE_ENDIANNES
+
+- Don't use 32 bit values for virtual addresses
--
1.6.0.4

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0004-staging-sep-Update-TODO.patch --]
[-- Type: text/x-diff; name="0004-staging-sep-Update-TODO.patch", Size: 1752 bytes --]

From 9230c90ce19747554354c9fc93b3b1c8e661894c Mon Sep 17 00:00:00 2001
From: Mark Allyn <mark.a.allyn@intel.com>
Date: Wed, 28 Apr 2010 14:41:39 -0700
Subject: RFC [PATCH 4/4] staging: sep: Update TODO

Signed-off-by: Mark A. Allyn <mark.a.allyn@intel.com>
---
 drivers/staging/sep/TODO |   36 ++++++++++++++++++++++++++++--------
 1 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/sep/TODO b/drivers/staging/sep/TODO
index ff0e931..1a8f876 100644
--- a/drivers/staging/sep/TODO
+++ b/drivers/staging/sep/TODO
@@ -1,8 +1,28 @@
-Todo's so far (from Alan Cox)
-- Fix firmware loading
-- Get firmware into firmware git tree
-- Review and tidy each algorithm function
-- Check whether it can be plugged into any of the kernel crypto API
-  interfaces
-- Do something about the magic shared memory interface and replace it
-  with something saner (in Linux terms)
+Todo's so far (from Mark Allyn)
+
+- Resolve issue wiht allowing user space software to handle
+  physical addresses
+
+- Determine device types at runtime
+
+- Ensure that all global variables be either static or be in a global structure;
+  preferably in structure
+
+- Fix formatting (it did pass checkpatch, but it's still awkward
+
+- Fix problems in singleton opens
+
+- Provide documentation on mutex, test and set, and other locking
+
+- Fix process exit logic in caller ID handler
+
+- Need to unmap memory in case of failure
+
+- Need to document errors
+
+- Fix the way the device is set up; let the probe do the stuff such as
+  registering the device with the driver
+
+- Use cpu_to_le or cpu_to_bt instead of SEP_CHANGE_ENDIANNES
+
+- Don't use 32 bit values for virtual addresses
-- 
1.6.0.4


             reply	other threads:[~2010-04-28 23:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-28 23:10 Epshteyn, Eugene [this message]
2010-04-29  3:38 ` Greg KH
2010-04-29 11:04 ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=753F67ADE6F5094C9F1DBA00D1BAA8D325518252AF@orsmsx501.amr.corp.intel.com \
    --to=eugene.epshteyn@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®