1. 09 May, 2013 1 commit
    • Tony Lindgren's avatar
      ARM: OMAP2+: Remove bogus IS_ERR_OR_NULL checking from id.c · b1dd11d6
      Tony Lindgren authored
      Commit 6770b211
       (ARM: OMAP2+: Export SoC information to userspace)
      had some broken return value handling as noted by Russell King:
      +       soc_dev = soc_device_register(soc_dev_attr);
      +       if (IS_ERR_OR_NULL(soc_dev)) {
      +               kfree(soc_dev_attr);
      +               return;
      +       }
      +       parent = soc_device_to_device(soc_dev);
      +       if (!IS_ERR_OR_NULL(parent))
      +               device_create_file(parent, &omap_soc_attr);
      This is nonsense.  For the first, IS_ERR() is sufficient.  For the second,
      tell me what error checking is required in the return value of this
      struct device *soc_device_to_device(struct soc_device *soc_dev)
              return &soc_dev->dev;
      when you've already determined that the passed soc_dev is a valid pointer.
      If you read the comments against the prototype:
       * soc_device_to_device - helper function to fetch struct device
       * @soc: Previously registered SoC device container
      struct device *soc_device_to_device(struct soc_device *soc);
      if "soc" is valid, it means the "previously registered SoC device container"
      must have succeeded and that can only happen if the struct device has been
      registered.  Ergo, there will always be a valid struct device pointer for
      any registered SoC device container.  Therefore, if soc_device_register()
      succeeds, then the return value from soc_device_to_device() will always be
      valid and no error checking of it is required.
      Simples.  The rule as ever applies here: get to know the APIs your using
      and don't fumble around in the dark hoping that you'll get this stuff
      Fix it as noted by Russell.
      Reported-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
  2. 08 May, 2013 5 commits
  3. 07 May, 2013 1 commit
  4. 06 May, 2013 2 commits
  5. 03 May, 2013 2 commits
    • Tony Lindgren's avatar
      ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP · eb16d332
      Tony Lindgren authored
      Commit 8a6201b9
       (ARM: OMAP2+: Fix unmet direct dependencies for zoom
      for 8250 serial) fixed unmet direct dependencies for 8250, but failed
      to do the same for omap serial. This can cause the following warning:
      warning: (ARCH_OMAP2PLUS_TYPICAL) selects SERIAL_OMAP which has
      unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS &&
      We should not select drivers, they should be selected by the
      user. Fix the issue by removing the select and adding them to
      omap2plus_defconfig instead.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
    • Arnd Bergmann's avatar
      ARM: OMAP: build SMP code only for OMAP4/5 · 572b16db
      Arnd Bergmann authored
      The OMAP platform code assumes that SMP is only ever enabled when
      CONFIG_ARCH_OMAP4 or CONFIG_SOC_OMAP5 is enabled, which is not
      necessarirly true in a multiplatform configuration.
      arch/arm/mach-omap2/built-in.o: In function `omap4_smp_prepare_cpus':
       :(.init.text+0x413c): undefined reference to `omap_get_wakeupgen_base'
       :(.init.text+0x415c): undefined reference to `omap_secure_apis_support'
      arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
       :(.cpuinit.text+0x28): undefined reference to `omap_get_wakeupgen_base'
       :(.cpuinit.text+0x3c): undefined reference to `omap_secure_apis_support'
      arch/arm/mach-omap2/built-in.o: In function `omap4_cpu_die':
       :(.ref.text+0x8): undefined reference to `omap_get_wakeupgen_base'
       :(.ref.text+0x10): undefined reference to `omap_secure_apis_support'
       :(.ref.text+0x4c): undefined reference to `omap4_hotplug_cpu'
       :(.ref.text+0x50): undefined reference to `omap_secure_apis_support'
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
  6. 02 May, 2013 2 commits
    • Russell King's avatar
      ARM: OMAP: use consistent error checking · c48cd659
      Russell King authored
      Consistently check errors using the usual method used in the kernel
      for much of its history.  For instance:
      int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
      	int div;
      	div = gpmc_calc_divider(t->sync_clk);
      	if (div < 0)
      		return div;
      static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
      	return gpmc_cs_set_timings(cs, t);
      	ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t);
      	if (IS_ERR_VALUE(ret))
      		return ret;
      So, gpmc_cs_set_timings() thinks any negative return value is an error,
      but where we check that in higher levels, only a limited range are
      There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really
      appropriate, and that is in arch/arm/include/asm/syscall.h:
      static inline long syscall_get_error(struct task_struct *task,
      				     struct pt_regs *regs)
      	unsigned long error = regs->ARM_r0;
      	return IS_ERR_VALUE(error) ? error : 0;
      because this function really does have to differentiate between error
      return values and addresses which look like negative numbers (eg, from
      So, here's a patch to remove them from OMAP, except for the above.
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • Russell King's avatar
      ARM: cleanup: OMAP hwmod error checking · 857835c6
      Russell King authored
      omap_hwmod_lookup() only returns NULL on error, never an error pointer.
      Checking the returned pointer using IS_ERR_OR_NULL() is needless
      overhead.  Use a simple !ptr check instead.
      OMAP devices (oh->od) always have a valid platform device attached (see
      omap_device_alloc()) so there's no point validating the platform device
      pointer (we will have already oopsed long before if this is not the
      case here.)
      Lastly, oh->od is only ever NULL or a valid omap device pointer - 'oh'
      comes from the statically declared hwmod tables, and the pointer is
      only filled in by omap_device_alloc() at a point where the omap device
      pointer must be valid.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  7. 30 Apr, 2013 2 commits
  8. 23 Apr, 2013 5 commits
  9. 21 Apr, 2013 1 commit
  10. 18 Apr, 2013 1 commit
  11. 14 Apr, 2013 1 commit
  12. 11 Apr, 2013 1 commit
    • Rob Herring's avatar
      ARM: convert arm/arm64 arch timer to use CLKSRC_OF init · 0583fe47
      Rob Herring authored
      This converts arm and arm64 to use CLKSRC_OF DT based initialization for
      the arch timer. A new function arch_timer_arch_init is added to allow for
      arch specific setup.
      This has a side effect of enabling sched_clock on omap5 and exynos5. There
      should not be any reason not to use the arch timers for sched_clock.
      Signed-off-by: default avatarRob Herring <rob.herring@calxeda.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: Magnus Damm <magnus.damm@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-samsung-soc@vger.kernel.org
      Cc: linux-omap@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
  13. 10 Apr, 2013 2 commits
    • Kishon Vijay Abraham I's avatar
      ARM: OMAP4: hwmod data: make 'ocp2scp_usb_phy_phy_48m" as the main clock · f4d7a536
      Kishon Vijay Abraham I authored
      Commit 92702df3
       ("ARM: OMAP4: PM: fix PM regression introduced by recent
      clock cleanup") makes the 'ocp2scp_usb_phy_phy_48m' as optional
      functional clock causing regression in MUSB. But this 48MHz clock is a
      mandatory clock for usb phy attached to ocp2scp and hence made as the main
      clock for ocp2scp.
      Cc: Keerthy <j-keerthy@ti.com>
      Cc: Benoît Cousson <b-cousson@ti.com>
      Cc: Paul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      [paul@pwsan.com: add comment to the hwmod data to try to prevent any
       future mistakes here]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
    • Nishanth Menon's avatar
      cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver · 49ded525
      Nishanth Menon authored
      As multi-platform build is being adopted by more and more ARM platforms,
      initcall function should be used very carefully.  For example, when
      CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
      will be called on all the platforms to initialize omap-cpufreq driver.
      Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
      tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
      for OMAP in a single image, we need to ensure the following:
       1. With device tree boot, we use cpufreq-cpu0
       2. With non device tree boot, we use omap-cpufreq
      In the case of (1), we will have cpu OPPs and regulator registered
      as part of the device tree nodes, to ensure that omap-cpufreq
      and cpufreq-cpu0 don't conflict in managing the frequency of the
      same CPU, we should not permit omap-cpufreq to be probed.
      In the case of (2), we will not have the cpufreq-cpu0 device, hence
      only omap-cpufreq will be active.
      To eliminate this undesired these effects, we change omap-cpufreq
      driver to have it instantiated as a platform_driver and register
      "omap-cpufreq" device only when booted without device tree nodes on
      OMAP platforms.
      This allows the following:
       a) Will only run on platforms that create the platform_device
       b) Since the platform_device is registered only when device tree nodes
          are *not* populated, omap-cpufreq driver does not conflict with
          the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
          device tree nodes are present.
      Inspired by commit 5553f9e2
      (cpufreq: instantiate cpufreq-cpu0 as a platform_driver)
      [robherring2@gmail.com: reported conflict of omap-cpufreq vs other
      driver in an non-device tree supported boot]
      Reported-by: default avatarRob Herring <robherring2@gmail.com>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarKevin Hilman <khilman@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  14. 09 Apr, 2013 7 commits
  15. 08 Apr, 2013 7 commits