1. 05 2月, 2013 1 次提交
  2. 25 12月, 2012 1 次提交
  3. 14 9月, 2012 1 次提交
  4. 05 1月, 2012 1 次提交
  5. 17 12月, 2011 1 次提交
  6. 14 11月, 2011 1 次提交
  7. 11 11月, 2011 1 次提交
  8. 17 10月, 2011 1 次提交
  9. 12 7月, 2011 1 次提交
  10. 21 3月, 2011 1 次提交
  11. 16 3月, 2011 1 次提交
  12. 27 2月, 2011 1 次提交
  13. 16 12月, 2010 2 次提交
  14. 01 12月, 2010 1 次提交
  15. 20 10月, 2010 1 次提交
    • N
      arm: remove machine_desc.io_pg_offst and .phys_io · 6451d778
      Nicolas Pitre 提交于
      Since we're now using addruart to establish the debug mapping, we can
      remove the io_pg_offst and phys_io members of struct machine_desc.
      
      The various declarations were removed using the following script:
      
        grep -rl MACHINE_START arch/arm | xargs \
        sed -i '/MACHINE_START/,/MACHINE_END/ { /\.\(phys_io\|io_pg_offst\)/d }'
      
      [ Initial patch was from Jeremy Kerr, example script from Russell King ]
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Acked-by: Eric Miao <eric.miao at canonical.com>
      6451d778
  16. 08 10月, 2010 1 次提交
  17. 16 7月, 2010 1 次提交
  18. 11 5月, 2010 1 次提交
  19. 02 3月, 2010 1 次提交
  20. 01 12月, 2009 1 次提交
  21. 10 9月, 2009 2 次提交
  22. 05 6月, 2009 1 次提交
  23. 04 6月, 2009 1 次提交
    • J
      rfkill: rewrite · 19d337df
      Johannes Berg 提交于
      This patch completely rewrites the rfkill core to address
      the following deficiencies:
      
       * all rfkill drivers need to implement polling where necessary
         rather than having one central implementation
      
       * updating the rfkill state cannot be done from arbitrary
         contexts, forcing drivers to use schedule_work and requiring
         lots of code
      
       * rfkill drivers need to keep track of soft/hard blocked
         internally -- the core should do this
      
       * the rfkill API has many unexpected quirks, for example being
         asymmetric wrt. alloc/free and register/unregister
      
       * rfkill can call back into a driver from within a function the
         driver called -- this is prone to deadlocks and generally
         should be avoided
      
       * rfkill-input pointlessly is a separate module
      
       * drivers need to #ifdef rfkill functions (unless they want to
         depend on or select RFKILL) -- rfkill should provide inlines
         that do nothing if it isn't compiled in
      
       * the rfkill structure is not opaque -- drivers need to initialise
         it correctly (lots of sanity checking code required) -- instead
         force drivers to pass the right variables to rfkill_alloc()
      
       * the documentation is hard to read because it always assumes the
         reader is completely clueless and contains way TOO MANY CAPS
      
       * the rfkill code needlessly uses a lot of locks and atomic
         operations in locked sections
      
       * fix LED trigger to actually change the LED when the radio state
         changes -- this wasn't done before
      Tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
      Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      19d337df
  24. 18 5月, 2009 1 次提交
  25. 04 4月, 2009 1 次提交
  26. 20 3月, 2009 1 次提交
    • R
      [ARM] pass reboot command line to arch_reset() · be093beb
      Russell King 提交于
      OMAP wishes to pass state to the boot loader upon reboot in order to
      instruct it whether to wait for USB-based reflashing or not.  There is
      already a facility to do this via the reboot() syscall, except we ignore
      the string passed to machine_restart().
      
      This patch fixes things to pass this string to arch_reset().  This means
      that we keep the reboot mode limited to telling the kernel _how_ to
      perform the reboot which should be independent of what we request the
      boot loader to do.
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      be093beb
  27. 19 3月, 2009 1 次提交
  28. 09 3月, 2009 1 次提交
    • E
      [ARM] pxa: introduce pxa{25x,27x,300,320,930}.h for board usage · 51c62982
      Eric Miao 提交于
      Considering the header mess ATM, it is not always possible to include
      the correct header files within board code. Let's keep this simple:
      
        <mach/pxa25x.h>  - for pxa25x based platforms
        <mach/pxa27x.h>  - for pxa27x based platforms
        <mach/pxa300.h>  - for pxa300 based platforms
        <mach/pxa320.h>  - for pxa320 based platforms
        <mach/pxa930.h>  - for pxa930 based platforms
      
      NOTE:
      
      1. one header one board file, they are not compatible (i.e. they have
         conflicting definitions which won't compile if included together).
      
      2. Unless strictly necessary, the following header files are considered
         to be SoC files use _only_, and is not recommended to be included in
         board code:
      
          <mach/hardware.h>
          <mach/pxa-regs.h>
          <mach/pxa2xx-regs.h>
          <mach/pxa3xx-regs.h>
          <mach/mfp.h>
          <mach/mfp-pxa2xx.h>
          <mach/mfp-pxa25x.h>
          <mach/mfp-pxa27x.h>
          <mach/mfp-pxa3xx.h>
          <mach/mfp-pxa300.h>
          <mach/mfp-pxa320.h>
          <mach/mfp-pxa930.h>
      Signed-off-by: NEric Miao <eric.miao@marvell.com>
      51c62982
  29. 02 12月, 2008 3 次提交
  30. 21 10月, 2008 1 次提交
  31. 20 10月, 2008 2 次提交
  32. 11 10月, 2008 1 次提交
  33. 14 9月, 2008 2 次提交
  34. 07 8月, 2008 1 次提交