#6010 HIGH Update.: The EC SCI mask should be set in "sleep" mode.

[Zarro Boogs per Child]

#6010: The EC SCI mask should be set in "sleep" mode.
---------------------+------------------------------------------------------
  Reporter:  cjb     |       Owner:  dsaxena         
      Type:  defect  |      Status:  assigned        
  Priority:  high    |   Milestone:  Update.2 (8.2.0)
 Component:  kernel  |     Version:                  
Resolution:          |    Keywords:                  
  Verified:  0       |    Blocking:  5974            
 Blockedby:          |  
---------------------+------------------------------------------------------
Changes (by dsaxena):

 * cc: dilinger (added)


Comment:

 Replying to [comment:11 mstone]:
 >  Consequently, and speaking generally, I would be happiest if an
 underlying atomic interface were provided when possible and if a "high-
 level shell" interface were made available separately. Any reason it's
 inappropriate for the kernel to provide both? (Or to build the high-level
 one in userspace atop the atomic kernel one?)

 A sysfs one-file-per-bit interface guarantee an atomic update of the mask
 via a read/write lock. Yes, there exists the possibility of two
 applications writing to the same bit back to back, but at the system
 level, we should not have multiple entities managing these bits. I would
 like write code that has a chance of being accepted upstream w/o a major
 rewrite and if we're going with sysfs, that may mean doing things in what
 seems a somewhat roundabout manner.

 I've gone ahead and implemented the sysfs interface as this as it was
 fairly trivial; however, I'm wondering if in the long-run it may be better
 to not use sysfs and instead provide a full EC driver of some sort that
 exposes the EC interface to user space to do with it as it pleases. There
 seem to be multiple cases where we need to poke at the EC from OHM and
 adding a new sysfs file every time we need to poke at something is not
 very  efficient. This could be wrapped in a library that could be called
 by OHM or utilities for use on the shell. That's a topic that should be
 discussed outside this bug.

-- 
Ticket URL: <http://dev.laptop.org/ticket/6010#comment:12>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system