1. 17 Jul, 2017 1 commit
    • Joel Stanley's avatar
      fsi: core: register with postcore_initcall · 496f8931
      Joel Stanley authored
      When testing an i2c driver that is a fsi bus driver, I saw the following
      oops:
      
       kernel BUG at drivers/base/driver.c:153!
       Internal error: Oops - BUG: 0 [#1] ARM
      
       [<8027cb1c>] (driver_register) from [<80344e88>] (fsi_driver_register+0x2c/0x38)
       [<80344e88>] (fsi_driver_register) from [<805f5ebc>] (fsi_i2c_driver_init+0x1c/0x24)
       [<805f5ebc>] (fsi_i2c_driver_init) from [<805d1f14>] (do_one_initcall+0xb4/0x170)
       [<805d1f14>] (do_one_initcall) from [<805d20f0>] (kernel_init_freeable+0x120/0x1dc)
       [<805d20f0>] (kernel_init_freeable) from [<8043f4a8>] (kernel_init+0x18/0x104)
       [<8043f4a8>] (kernel_init) from [<8000a5e8>] (ret_from_fork+0x14/0x2c)
      
      This is because the fsi bus had not been registered. This fix registers the bus
      with postcore_initcall instead, to ensure it is registered earlier on.
      
      When the fsi core is used as a module this should not be a problem as the fsi
      driver will depend on the fsi bus type symbol, and will therefore load the core
      before the driver.
      
      Fixes: 0508ad1f
      
       ("drivers/fsi: Add empty fsi bus definitions")
      Signed-off-by: default avatarJoel Stanley <joel@jms.id.au>
      Acked-by: default avatarJeremy Kerr <jk@ozlabs.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      496f8931
  2. 09 Jun, 2017 17 commits
  3. 10 Feb, 2017 2 commits
  4. 27 Mar, 2015 1 commit
    • Suzuki K. Poulose's avatar
      arm-cci: Get rid of secure transactions for PMU driver · 772742a6
      Suzuki K. Poulose authored
      
      
      Avoid secure transactions while probing the CCI PMU. The
      existing code makes use of the Peripheral ID2 (PID2) register
      to determine the revision of the CCI400, which requires a
      secure transaction. This puts a limitation on the usage of the
      driver on systems running non-secure Linux(e.g, ARM64).
      
      Updated the device-tree binding for cci pmu node to add the explicit
      revision number for the compatible field.
      
      The supported strings are :
      	arm,cci-400-pmu,r0
      	arm,cci-400-pmu,r1
      	arm,cci-400-pmu - DEPRECATED. See NOTE below
      
      NOTE: If the revision is not mentioned, we need to probe the cci revision,
      which could be fatal on a platform running non-secure. We need a reliable way
      to know if we can poke the CCI registers at runtime on ARM32. We depend on
      'mcpm_is_available()' when it is available. mcpm_is_available() returns true
      only when there is a registered driver for mcpm. Otherwise, we assume that we
      don't have secure access, and skips probing the revision number(ARM64 case).
      
      The MCPM should figure out if it is safe to access the CCI. Unfortunately
      there isn't a reliable way to indicate the same via dtb. This patch doesn't
      address/change the current situation. It only deals with the CCI-PMU, leaving
      the assumptions about the secure access as it has been, prior to this patch.
      
      Cc: devicetree@vger.kernel.org
      Cc: Punit Agrawal <punit.agrawal@arm.com>
      Tested-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Acked-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarSuzuki K. Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      772742a6
  5. 11 Oct, 2012 1 commit
  6. 17 Sep, 2012 4 commits
  7. 17 Jul, 2007 1 commit
  8. 19 Jun, 2006 1 commit
  9. 09 Jan, 2006 2 commits
  10. 16 Nov, 2005 1 commit
  11. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4