1. 15 12月, 2011 3 次提交
    • K
      edac: convert sysdev_class to a regular subsystem · fe5ff8b8
      Kay Sievers 提交于
      After all sysdev classes are ported to regular driver core entities, the
      sysdev implementation will be entirely removed from the kernel.
      
      Cc: Doug Thompson <dougthompson@xmission.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fe5ff8b8
    • K
      driver-core: implement 'sysdev' functionality for regular devices and buses · ca22e56d
      Kay Sievers 提交于
      All sysdev classes and sysdev devices will converted to regular devices
      and buses to properly hook userspace into the event processing.
      
      There is no interesting difference between a 'sysdev' and 'device' which
      would justify to roll an entire own subsystem with different userspace
      export semantics. Userspace relies on events and generic sysfs subsystem
      infrastructure from sysdev devices, which are currently not properly
      available.
      
      Every converted sysdev class will create a regular device with the class
      name in /sys/devices/system and all registered devices will becom a children
      of theses devices.
      
      For compatibility reasons, the sysdev class-wide attributes are created
      at this parent device. (Do not copy that logic for anything new, subsystem-
      wide properties belong to the subsystem, not to some fake parent device
      created in /sys/devices.)
      
      Every sysdev driver is implemented as a simple subsystem interface now,
      and no longer called a driver.
      
      After all sysdev classes are ported to regular driver core entities, the
      sysdev implementation will be entirely removed from the kernel.
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ca22e56d
    • G
      kref: fix up the kfree build problems · 6261ddee
      Greg Kroah-Hartman 提交于
      It turns out that some memory allocators use kobjects, which use krefs,
      and kref.h was wanting to figure out the address of kfree(), which ended
      up in a loop.
      
      kfree was only being needed for a warning to tell the caller that they
      were doing something stupid.  Now we just move that warning into the
      comments for the functions, which results in a bit more fun as everyone
      enjoys digging for people to mock at times of boredom.
      
      So, remove the dependancy of slab.h on kref.h, and fix up the other
      include file as well (we really only need bug.h and atomic.h, not
      types.h).
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Oliver Neukum <oneukum@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6261ddee
  2. 14 12月, 2011 3 次提交
    • P
      kref: Remove the memory barriers · 3c8ed889
      Peter Zijlstra 提交于
      Commit 1b0b3b99 ("kref: fix CPU ordering with respect to krefs")
      wrongly adds memory barriers to kref.
      
      It states:
      
        some atomic operations are only atomic, not ordered. Thus a CPU is allowed
        to reorder memory references to an object to before the reference is
        obtained. This fixes it.
      
      While true, it fails to show why this is a problem. I say it is not a
      problem because if there is a race with kref_put() such that we could
      end up referencing a free'd object without this memory barrier, we
      would still have that race with the memory barrier.
      
      The kref_put() in question could complete (and free the object) before
      the atomic_inc() and we'd still be up shit creek.
      
      The kref_init() case is even worse, if your object is published at this
      time you're so wrong the memory barrier won't make a difference what
      so ever. If its not published, the act of publishing should include
      the needed barriers/locks to make sure all writes prior to the act of
      publishing are complete such that others will only observe a complete
      object.
      
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Oliver Neukum <oneukum@suse.de>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3c8ed889
    • P
      kref: Implement kref_put in terms of kref_sub · 47dbd7d9
      Peter Zijlstra 提交于
      Less lines of code is better.
      
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      47dbd7d9
    • P
      kref: Inline all functions · 4af679cd
      Peter Zijlstra 提交于
      These are tiny functions, there's no point in having them out-of-line.
      
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/n/tip-8eccvi2ur2fzgi00xdjlbf5z@git.kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4af679cd
  3. 10 12月, 2011 1 次提交
  4. 19 11月, 2011 2 次提交
  5. 18 11月, 2011 4 次提交
  6. 16 11月, 2011 1 次提交
  7. 07 11月, 2011 5 次提交
  8. 05 11月, 2011 4 次提交
  9. 04 11月, 2011 4 次提交
  10. 03 11月, 2011 13 次提交