1. 24 3月, 2011 1 次提交
    • R
      x86: Use syscore_ops instead of sysdev classes and sysdevs · f3c6ea1b
      Rafael J. Wysocki 提交于
      Some subsystems in the x86 tree need to carry out suspend/resume and
      shutdown operations with one CPU on-line and interrupts disabled and
      they define sysdev classes and sysdevs or sysdev drivers for this
      purpose.  This leads to unnecessarily complicated code and excessive
      memory usage, so switch them to using struct syscore_ops objects for
      this purpose instead.
      
      Generally, there are three categories of subsystems that use
      sysdevs for implementing PM operations: (1) subsystems whose
      suspend/resume callbacks ignore their arguments entirely (the
      majority), (2) subsystems whose suspend/resume callbacks use their
      struct sys_device argument, but don't really need to do that,
      because they can be implemented differently in an arguably simpler
      way (io_apic.c), and (3) subsystems whose suspend/resume callbacks
      use their struct sys_device argument, but the value of that argument
      is always the same and could be ignored (microcode_core.c).  In all
      of these cases the subsystems in question may be readily converted to
      using struct syscore_ops objects for power management and shutdown.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      f3c6ea1b
  2. 09 2月, 2011 1 次提交
  3. 18 10月, 2010 1 次提交
  4. 15 10月, 2010 1 次提交
    • A
      llseek: automatically add .llseek fop · 6038f373
      Arnd Bergmann 提交于
      All file_operations should get a .llseek operation so we can make
      nonseekable_open the default for future file operations without a
      .llseek pointer.
      
      The three cases that we can automatically detect are no_llseek, seq_lseek
      and default_llseek. For cases where we can we can automatically prove that
      the file offset is always ignored, we use noop_llseek, which maintains
      the current behavior of not returning an error from a seek.
      
      New drivers should normally not use noop_llseek but instead use no_llseek
      and call nonseekable_open at open time.  Existing drivers can be converted
      to do the same when the maintainer knows for certain that no user code
      relies on calling seek on the device file.
      
      The generated code is often incorrectly indented and right now contains
      comments that clarify for each added line why a specific variant was
      chosen. In the version that gets submitted upstream, the comments will
      be gone and I will manually fix the indentation, because there does not
      seem to be a way to do that using coccinelle.
      
      Some amount of new code is currently sitting in linux-next that should get
      the same modifications, which I will do at the end of the merge window.
      
      Many thanks to Julia Lawall for helping me learn to write a semantic
      patch that does all this.
      
      ===== begin semantic patch =====
      // This adds an llseek= method to all file operations,
      // as a preparation for making no_llseek the default.
      //
      // The rules are
      // - use no_llseek explicitly if we do nonseekable_open
      // - use seq_lseek for sequential files
      // - use default_llseek if we know we access f_pos
      // - use noop_llseek if we know we don't access f_pos,
      //   but we still want to allow users to call lseek
      //
      @ open1 exists @
      identifier nested_open;
      @@
      nested_open(...)
      {
      <+...
      nonseekable_open(...)
      ...+>
      }
      
      @ open exists@
      identifier open_f;
      identifier i, f;
      identifier open1.nested_open;
      @@
      int open_f(struct inode *i, struct file *f)
      {
      <+...
      (
      nonseekable_open(...)
      |
      nested_open(...)
      )
      ...+>
      }
      
      @ read disable optional_qualifier exists @
      identifier read_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      expression E;
      identifier func;
      @@
      ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
      {
      <+...
      (
         *off = E
      |
         *off += E
      |
         func(..., off, ...)
      |
         E = *off
      )
      ...+>
      }
      
      @ read_no_fpos disable optional_qualifier exists @
      identifier read_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      @@
      ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
      {
      ... when != off
      }
      
      @ write @
      identifier write_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      expression E;
      identifier func;
      @@
      ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
      {
      <+...
      (
        *off = E
      |
        *off += E
      |
        func(..., off, ...)
      |
        E = *off
      )
      ...+>
      }
      
      @ write_no_fpos @
      identifier write_f;
      identifier f, p, s, off;
      type ssize_t, size_t, loff_t;
      @@
      ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
      {
      ... when != off
      }
      
      @ fops0 @
      identifier fops;
      @@
      struct file_operations fops = {
       ...
      };
      
      @ has_llseek depends on fops0 @
      identifier fops0.fops;
      identifier llseek_f;
      @@
      struct file_operations fops = {
      ...
       .llseek = llseek_f,
      ...
      };
      
      @ has_read depends on fops0 @
      identifier fops0.fops;
      identifier read_f;
      @@
      struct file_operations fops = {
      ...
       .read = read_f,
      ...
      };
      
      @ has_write depends on fops0 @
      identifier fops0.fops;
      identifier write_f;
      @@
      struct file_operations fops = {
      ...
       .write = write_f,
      ...
      };
      
      @ has_open depends on fops0 @
      identifier fops0.fops;
      identifier open_f;
      @@
      struct file_operations fops = {
      ...
       .open = open_f,
      ...
      };
      
      // use no_llseek if we call nonseekable_open
      ////////////////////////////////////////////
      @ nonseekable1 depends on !has_llseek && has_open @
      identifier fops0.fops;
      identifier nso ~= "nonseekable_open";
      @@
      struct file_operations fops = {
      ...  .open = nso, ...
      +.llseek = no_llseek, /* nonseekable */
      };
      
      @ nonseekable2 depends on !has_llseek @
      identifier fops0.fops;
      identifier open.open_f;
      @@
      struct file_operations fops = {
      ...  .open = open_f, ...
      +.llseek = no_llseek, /* open uses nonseekable */
      };
      
      // use seq_lseek for sequential files
      /////////////////////////////////////
      @ seq depends on !has_llseek @
      identifier fops0.fops;
      identifier sr ~= "seq_read";
      @@
      struct file_operations fops = {
      ...  .read = sr, ...
      +.llseek = seq_lseek, /* we have seq_read */
      };
      
      // use default_llseek if there is a readdir
      ///////////////////////////////////////////
      @ fops1 depends on !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier readdir_e;
      @@
      // any other fop is used that changes pos
      struct file_operations fops = {
      ... .readdir = readdir_e, ...
      +.llseek = default_llseek, /* readdir is present */
      };
      
      // use default_llseek if at least one of read/write touches f_pos
      /////////////////////////////////////////////////////////////////
      @ fops2 depends on !fops1 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier read.read_f;
      @@
      // read fops use offset
      struct file_operations fops = {
      ... .read = read_f, ...
      +.llseek = default_llseek, /* read accesses f_pos */
      };
      
      @ fops3 depends on !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier write.write_f;
      @@
      // write fops use offset
      struct file_operations fops = {
      ... .write = write_f, ...
      +	.llseek = default_llseek, /* write accesses f_pos */
      };
      
      // Use noop_llseek if neither read nor write accesses f_pos
      ///////////////////////////////////////////////////////////
      
      @ fops4 depends on !fops1 && !fops2 && !fops3 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier read_no_fpos.read_f;
      identifier write_no_fpos.write_f;
      @@
      // write fops use offset
      struct file_operations fops = {
      ...
       .write = write_f,
       .read = read_f,
      ...
      +.llseek = noop_llseek, /* read and write both use no f_pos */
      };
      
      @ depends on has_write && !has_read && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier write_no_fpos.write_f;
      @@
      struct file_operations fops = {
      ... .write = write_f, ...
      +.llseek = noop_llseek, /* write uses no f_pos */
      };
      
      @ depends on has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      identifier read_no_fpos.read_f;
      @@
      struct file_operations fops = {
      ... .read = read_f, ...
      +.llseek = noop_llseek, /* read uses no f_pos */
      };
      
      @ depends on !has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
      identifier fops0.fops;
      @@
      struct file_operations fops = {
      ...
      +.llseek = noop_llseek, /* no read or write fn */
      };
      ===== End semantic patch =====
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Julia Lawall <julia@diku.dk>
      Cc: Christoph Hellwig <hch@infradead.org>
      6038f373
  5. 26 5月, 2010 1 次提交
    • K
      driver core: add devname module aliases to allow module on-demand auto-loading · 578454ff
      Kay Sievers 提交于
      This adds:
        alias: devname:<name>
      to some common kernel modules, which will allow the on-demand loading
      of the kernel module when the device node is accessed.
      
      Ideally all these modules would be compiled-in, but distros seems too
      much in love with their modularization that we need to cover the common
      cases with this new facility. It will allow us to remove a bunch of pretty
      useless init scripts and modprobes from init scripts.
      
      The static device node aliases will be carried in the module itself. The
      program depmod will extract this information to a file in the module directory:
        $ cat /lib/modules/2.6.34-00650-g537b60d1-dirty/modules.devname
        # Device nodes to trigger on-demand module loading.
        microcode cpu/microcode c10:184
        fuse fuse c10:229
        ppp_generic ppp c108:0
        tun net/tun c10:200
        dm_mod mapper/control c10:235
      
      Udev will pick up the depmod created file on startup and create all the
      static device nodes which the kernel modules specify, so that these modules
      get automatically loaded when the device node is accessed:
        $ /sbin/udevd --debug
        ...
        static_dev_create_from_modules: mknod '/dev/cpu/microcode' c10:184
        static_dev_create_from_modules: mknod '/dev/fuse' c10:229
        static_dev_create_from_modules: mknod '/dev/ppp' c108:0
        static_dev_create_from_modules: mknod '/dev/net/tun' c10:200
        static_dev_create_from_modules: mknod '/dev/mapper/control' c10:235
        udev_rules_apply_static_dev_perms: chmod '/dev/net/tun' 0666
        udev_rules_apply_static_dev_perms: chmod '/dev/fuse' 0666
      
      A few device nodes are switched to statically allocated numbers, to allow
      the static nodes to work. This might also useful for systems which still run
      a plain static /dev, which is completely unsafe to use with any dynamic minor
      numbers.
      
      Note:
      The devname aliases must be limited to the *common* and *single*instance*
      device nodes, like the misc devices, and never be used for conceptually limited
      systems like the loop devices, which should rather get fixed properly and get a
      control node for losetup to talk to, instead of creating a random number of
      device nodes in advance, regardless if they are ever used.
      
      This facility is to hide the mess distros are creating with too modualized
      kernels, and just to hide that these modules are not compiled-in, and not to
      paper-over broken concepts. Thanks! :)
      
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: Chris Mason <chris.mason@oracle.com>
      Cc: Alasdair G Kergon <agk@redhat.com>
      Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Cc: Ian Kent <raven@themaw.net>
      Signed-Off-By: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      578454ff
  6. 14 4月, 2010 1 次提交
  7. 23 1月, 2010 1 次提交
  8. 24 12月, 2009 1 次提交
    • L
      Revert "x86, ucode-amd: Ensure ucode update on suspend/resume after CPU off/online cycle" · 2f99f5c8
      Linus Torvalds 提交于
      This reverts commit 9f15226e.  It's just
      wrong, and broke resume for Rafael even on a non-AMD CPU.
      
      As Rafael says:
       "... it causes microcode_init_cpu() to be called during resume even for
        CPUs for which there's no microcode to apply.  That, in turn, results
        in executing request_firmware() (on Intel CPUs at least) which doesn't
        work at this stage of resume (we have device interrupts disabled, I/O
        devices are still suspended and so on).
      
        If I'm not mistaken, the "if (uci->valid)" logic means "if that CPU is
        known to us" , so before commit 9f15226e microcode_resume_cpu() was
        called for all CPUs already in the system during suspend, which was
        the right thing to do.  The commit changed it so that the CPUs without
        microcode to apply are now treated as "unknown", which is not quite
        right.
      
        The problem this commit attempted to solve has to be handled
        differently."
      
      Bisected-and -requested-by: Rafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2f99f5c8
  9. 09 12月, 2009 1 次提交
  10. 12 11月, 2009 1 次提交
    • A
      x86, ucode-amd: Ensure ucode update on suspend/resume after CPU off/online cycle · 9f15226e
      Andreas Herrmann 提交于
      When switching a CPU offline/online and then doing
      suspend/resume, ucode is not updated on this CPU.
      
      This is due to the microcode_fini_cpu() call which frees uci->mc
      when setting the CPU offline:
      
        static void microcode_fini_cpu_amd(int cpu)
        {
                struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
      
                vfree(uci->mc);
                uci->mc = NULL;
        }
      
      When the CPU is set online uci->mc is still NULL because no
      ucode update is required.
      
      Finally this prevents ucode update when resuming after suspend:
      
        static enum ucode_state microcode_resume_cpu(int cpu)
        {
              struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
      
              if (!uci->mc)
                      return UCODE_NFOUND;
      
              ...
        }
      
      Fix is to check whether uci->mc is valid before
      microcode_resume_cpu() is called.
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: dimm <dmitry.adamushko@gmail.com>
      LKML-Reference: <20091111190329.GF18592@alberich.amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9f15226e
  11. 10 11月, 2009 1 次提交
  12. 14 10月, 2009 1 次提交
  13. 22 9月, 2009 1 次提交
  14. 20 9月, 2009 1 次提交
  15. 16 6月, 2009 1 次提交
  16. 12 5月, 2009 1 次提交
    • D
      x86: microcode: use smp_call_function_single instead of set_cpus_allowed,... · 871b72dd
      Dmitry Adamushko 提交于
      x86: microcode: use smp_call_function_single instead of set_cpus_allowed, cleanup of synchronization logic
      
      * Solve issues described in 6f66cbc6
        in a way that doesn't resort to set_cpus_allowed();
      
      * in fact, only collect_cpu_info and apply_microcode callbacks
        must run on a target cpu, others will do just fine on any other.
        smp_call_function_single() (as suggested by Ingo) is used to run
        these callbacks on a target cpu.
      
      * cleanup of synchronization logic of the 'microcode_core' part
      
        The generic 'microcode_core' part guarantees that only a single cpu
        (be it a full-fledged cpu, one of the cores or HT)
        is being updated at any particular moment of time.
      
        In general, there is no need for any additional sync. mechanism in
        arch-specific parts (the patch removes existing spinlocks).
      
        See also the "Synchronization" section in microcode_core.c.
      
      * return -EINVAL instead of -1 (which is translated into -EPERM) in
        microcode_write(), reload_cpu() and mc_sysdev_add(). Other suggestions
        for an error code?
      
      * use 'enum ucode_state' as return value of request_microcode_{fw, user}
        to gain more flexibility by distinguishing between real error cases
        and situations when an appropriate ucode was not found (which is not an
        error per-se).
      
      * some minor cleanups
      
      Thanks a lot to Hugh Dickins for review/suggestions/testing!
      
         Reference: http://marc.info/?l=linux-kernel&m=124025889012541&w=2
      
      [ Impact: refactor and clean up microcode driver locking code ]
      Signed-off-by: NDmitry Adamushko <dmitry.adamushko@gmail.com>
      Acked-by: NHugh Dickins <hugh@veritas.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Peter Oruba <peter.oruba@amd.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      LKML-Reference: <1242078507.5560.9.camel@earth>
      [ did some more cleanups ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
       arch/x86/include/asm/microcode.h  |   25 ++
       arch/x86/kernel/microcode_amd.c   |   58 ++----
       arch/x86/kernel/microcode_core.c  |  326 +++++++++++++++++++++-----------------
       arch/x86/kernel/microcode_intel.c |   92 +++-------
       4 files changed, 261 insertions(+), 240 deletions(-)
      
      (~20 new comment lines)
      871b72dd
  17. 17 4月, 2009 1 次提交
    • D
      x86: fix microcode driver newly spewing warnings · 0917798d
      Dmitry Adamushko 提交于
      Jeff Garzik reported this WARN_ON() noise:
      
      > Kernel: 2.6.30-rc1-00306-g8371f87c
      > Hardware: ICH10 x86-64
      >
      > This is a regression from 2.6.29.  Microcode spews the following WARNING
      > multiple times during boot:
      >
      > ------------[ cut here ]------------
      > WARNING: at fs/sysfs/group.c:138 sysfs_remove_group+0xeb/0xf0()
      > Hardware name:         sysfs group ffffffffa0209700 not found for
      >  kobject 'cpu0'
      
      Keep sysfs files around for cpus even when we failed to locate
      microcode for them at the moment of module loading. The appropriate
      microcode firmware can become available later on.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0917798d
  18. 15 4月, 2009 1 次提交
    • H
      x86 microcode: revert some work_on_cpu · 6f66cbc6
      Hugh Dickins 提交于
      Revert part of af5c820a ("x86: cpumask:
      use work_on_cpu in arch/x86/kernel/microcode_core.c")
      
      That change is causing only one Intel CPU's microcode to be updated e.g.
      microcode: CPU3 updated from revision 0x9 to 0x17, date = 2005-04-22
      where before it announced that also for CPU0 and CPU1 and CPU2.
      
      We cannot use work_on_cpu() in the CONFIG_MICROCODE_OLD_INTERFACE code,
      because Intel's request_microcode_user() involves a copy_from_user() from
      /sbin/microcode_ctl, which therefore needs to be on that CPU at the time.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6f66cbc6
  19. 18 3月, 2009 2 次提交
    • I
      x86: microcode: cleanup · 4bae1967
      Ingo Molnar 提交于
      Impact: cleanup
      
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dmitry Adamushko <dmitry.adamushko@gmail.com>
      Cc: Peter Oruba <peter.oruba@amd.com>
      LKML-Reference: <200903111632.37279.rusty@rustcorp.com.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4bae1967
    • R
      x86: cpumask: use work_on_cpu in arch/x86/kernel/microcode_core.c · af5c820a
      Rusty Russell 提交于
      Impact: don't play with current's cpumask
      
      Straightforward indirection through work_on_cpu().  One change is
      that the error code from microcode_update_cpu() is now actually
      plumbed back to microcode_init_cpu(), so now we printk if it fails
      on cpu hotplug.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dmitry Adamushko <dmitry.adamushko@gmail.com>
      Cc: Peter Oruba <peter.oruba@amd.com>
      LKML-Reference: <200903111632.37279.rusty@rustcorp.com.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      af5c820a
  20. 20 12月, 2008 1 次提交
    • D
      x86: fix resume (S2R) broken by Intel microcode module, on A110L · 280a9ca5
      Dmitry Adamushko 提交于
      Impact: fix deadlock
      
      This is in response to the following bug report:
      
      Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12100
      Subject         : resume (S2R) broken by Intel microcode module, on A110L
      Submitter       : Andreas Mohr <andi@lisas.de>
      Date            : 2008-11-25 08:48 (19 days old)
      Handled-By      : Dmitry Adamushko <dmitry.adamushko@gmail.com>
      
      [ The deadlock scenario has been discovered by Andreas Mohr ]
      
      I think I might have a logical explanation why the system:
      
        (http://bugzilla.kernel.org/show_bug.cgi?id=12100)
      
      might hang upon resuming, OTOH it should have likely hanged each and every time.
      
      (1) possible deadlock in microcode_resume_cpu() if either 'if' section is
      taken;
      
      (2) now, I don't see it in spec. and can't experimentally verify it (newer
      ucodes don't seem to be available for my Core2duo)... but logically-wise, I'd
      think that when read upon resuming, the 'microcode revision' (MSR 0x8B) should
      be back to its original one (we need to reload ucode anyway so it doesn't seem
      logical if a cpu doesn't drop the version)... if so, the comparison with
      memcmp() for the full 'struct cpu_signature' is wrong... and that's how one of
      the aforementioned 'if' sections might have been triggered - leading to a
      deadlock.
      
      Obviously, in my tests I simulated loading/resuming with the ucode of the same
      version (just to see that the file is loaded/re-loaded upon resuming) so this
      issue has never popped up.
      
      I'd appreciate if someone with an appropriate system might give a try to the
      2nd patch (titled "fix a comparison && deadlock...").
      
      In any case, the deadlock situation is a must-have fix.
      Reported-by: NAndreas Mohr <andi@lisas.de>
      Signed-off-by: NDmitry Adamushko <dmitry.adamushko@gmail.com>
      Tested-by: NAndreas Mohr <andi@lisas.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      280a9ca5
  21. 26 11月, 2008 1 次提交
    • H
      x86: microcode: fix sparse warnings · 4db646b1
      Hannes Eder 提交于
      Impact: make global variables and a function static
      
      Fix following sparse warnings:
      
        arch/x86/kernel/microcode_core.c:102:22: warning: symbol
        'microcode_ops' was not declared. Should it be static?
        arch/x86/kernel/microcode_core.c:206:24: warning: symbol
        'microcode_pdev' was not declared. Should it be static?
        arch/x86/kernel/microcode_core.c:322:6: warning: symbol
        'microcode_update_cpu' was not declared. Should it be static?
        arch/x86/kernel/microcode_intel.c:468:22: warning: symbol
        'microcode_intel_ops' was not declared. Should it be static?
      Signed-off-by: NHannes Eder <hannes@hanneseder.net>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4db646b1
  22. 28 10月, 2008 1 次提交
  23. 02 10月, 2008 1 次提交
  24. 24 9月, 2008 1 次提交
  25. 23 9月, 2008 1 次提交
  26. 14 9月, 2008 1 次提交
  27. 12 9月, 2008 1 次提交
    • D
      x86, microcode rework, v2 · a0a29b62
      Dmitry Adamushko 提交于
      this is a rework of the microcode splitup in tip/x86/microcode
      
      (1) I think this new interface is cleaner (look at the changes
          in 'struct microcode_ops' in microcode.h);
      
      (2) it's -64 lines of code;
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a0a29b62
  28. 20 8月, 2008 1 次提交
    • D
      x86-microcode: generic interface refactoring · d45de409
      Dmitry Adamushko 提交于
      This is the 1st patch in the series. Here the aim was to avoid any
      significant changes, logically-wise.
      
      So it's mainly about generic interface refactoring: e.g. make
      microcode_{intel,amd}.c more about arch-specific details and less
      about policies like make-sure-we-run-on-a-target-cpu
      (no more set_cpus_allowed_ptr() here) and generic synchronization (no
      more microcode_mutex here).
      
      All in all, more line have been deleted than added.
      
      4 files changed, 145 insertions(+), 198 deletions(-)
      Signed-off-by: NDmitry Adamushko <dmitry.adamushko@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d45de409
  29. 15 8月, 2008 2 次提交
  30. 29 7月, 2008 8 次提交
  31. 26 7月, 2008 1 次提交