1. 03 5月, 2013 2 次提交
    • R
      ARM: OMAP: use consistent error checking · c48cd659
      Russell King 提交于
      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
      errors...
      
      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
      mmap()).
      
      So, here's a patch to remove them from OMAP, except for the above.
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c48cd659
    • R
      ARM: cleanup: OMAP hwmod error checking · 857835c6
      Russell King 提交于
      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: NRussell King <rmk+kernel@arm.linux.org.uk>
      857835c6
  2. 24 4月, 2013 1 次提交
    • A
      ARM: OMAP2+: add dependencies on ARCH_MULTI_V6/V7 · 4b0ed696
      Arnd Bergmann 提交于
      CONFIG_ARCH_OMAP2PLUS depends on (ARCH_MULTI_V6 || ARCH_MULTI_V7) as of
      a0694861 "ARM: OMAP2+: Enable ARCH_MULTIPLATFORM support", but the
      individual OMAP2/3/4/5 and AM33XX platforms can all be selected independent
      of what we are building for, which is a bug and prevents us from easily
      building e.g. an ARMv7-only defconfig.
      
      This makes ARCH_OMAP2 depend on ARCH_MULTI_V6 and the others depend on
      ARCH_MULTI_V7, to ensure we really only build the platforms for the
      CPUs we have enabled in the global multiplatform configuration step.
      
      Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      4b0ed696
  3. 23 4月, 2013 3 次提交
  4. 22 4月, 2013 1 次提交
  5. 19 4月, 2013 1 次提交
  6. 11 4月, 2013 1 次提交
  7. 10 4月, 2013 8 次提交
  8. 09 4月, 2013 5 次提交
  9. 08 4月, 2013 1 次提交
  10. 06 4月, 2013 1 次提交
  11. 04 4月, 2013 10 次提交
  12. 03 4月, 2013 6 次提交