1. 11 9月, 2012 9 次提交
  2. 24 8月, 2012 1 次提交
    • F
      mfd: lpc_ich: Fix a 3.5 kernel regression for iTCO_wdt driver · 092369ef
      Feng Tang 提交于
      There are many reports (including 2 of my machines) that iTCO_wdt watchdog
      driver fails to be initialized in 3.5 kernel with error message like:
      
      [    5.265175] ACPI Warning: 0x00001060-0x0000107f SystemIO conflicts with Region \_SB_.PCI0.LPCB.TCOI 1 (20120320/utaddress-251)
      [    5.265192] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
      [    5.265206] lpc_ich: Resource conflict(s) found affecting iTCO_wdt
      
      The root cause the iTCO_wdt driver in 3.4 probes the HW IO resource from
      LPC's PCI config space, while in 3.5 kernel it relies on lpc_ich driver
      for the probe, which adds a new acpi_check_resource_conflict() check, and
      give up the probe if there is any conflict with ACPI.
      
      Fix it by removing all the checks for iTCO_wdt to keep the same behavior as
      3.4 kernel.
      https://bugzilla.kernel.org/show_bug.cgi?id=44991
      
      Actually the same check could be removed for the gpio-ich in lpc_ich.c,
      but I'm not sure if it will cause problems.
      Signed-off-by: NFeng Tang <feng.tang@intel.com>
      Cc: Aaron Sierra <asierra@xes-inc.com>
      Cc: Wim Van Sebroeck <wim@iguana.be>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Bob Moore <robert.moore@intel.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      092369ef
  3. 22 8月, 2012 1 次提交
    • A
      mfd: Move tps65217 regulator plat data handling to regulator · 817bb7fb
      AnilKumar Ch 提交于
      Regulator platform data handling was mistakenly added to MFD
      driver. So we will see build errors if we compile MFD drivers
      without CONFIG_REGULATOR. This patch moves regulator platform
      data handling from TPS65217 MFD driver to regulator driver.
      
      This makes MFD driver independent of REGULATOR framework so
      build error is fixed if CONFIG_REGULATOR is not set.
      
      drivers/built-in.o: In function `tps65217_probe':
      tps65217.c:(.devinit.text+0x13e37): undefined reference
      to `of_regulator_match'
      
      This patch also fix allocation size of tps65217 platform data.
      Current implementation allocates a struct tps65217_board for each
      regulator specified in the device tree. But the structure itself
      provides array of regulators so one instance of it is sufficient.
      Signed-off-by: NAnilKumar Ch <anilkumar@ti.com>
      817bb7fb
  4. 09 8月, 2012 2 次提交
    • A
      ARM: pxa: remove irq_to_gpio from ezx-pcap driver · 59ee93a5
      Arnd Bergmann 提交于
      The irq_to_gpio function was removed from the pxa platform
      in linux-3.2, and this driver has been broken since.
      
      There is actually no in-tree user of this driver that adds
      this platform device, but the driver can and does get enabled
      on some platforms.
      
      Without this patch, building ezx_defconfig results in:
      
      drivers/mfd/ezx-pcap.c: In function 'pcap_isr_work':
      drivers/mfd/ezx-pcap.c:205:2: error: implicit declaration of function 'irq_to_gpio' [-Werror=implicit-function-declaration]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
      Cc: stable@vger.kernel.org (v3.2+)
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Cc: Daniel Ribeiro <drwyrm@gmail.com>
      59ee93a5
    • A
      mfd/asic3: fix asic3_mfd_probe return value · b2f0fa82
      Arnd Bergmann 提交于
      In commit 4f304245 "mfd: Set asic3 DS1WM clock_rate", a possible
      path through asic3_mfd_probe was introduced that would lead to
      an unpredictable return value, if everything succeeds but there
      are pdata->leds is NULL. This was reported correctly by gcc.
      
      Without this patch, building magician_defconfig results in:
      
      drivers/mfd/asic3.c: In function 'asic3_mfd_probe':
      drivers/mfd/asic3.c:940:2: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Paul Parsons <lost.distance@yahoo.com>
      Cc: Philipp Zabel <philipp.zabel@gmail.com>
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      b2f0fa82
  5. 27 7月, 2012 2 次提交
    • L
      mfd: Ensure AB8500 platform data is passed through db8500-prcmu to MFD Core · 3c1534c7
      Lee Jones 提交于
      When booting via platform code the AB8500 platform data is now passed
      in though the DB8500. However, if pdata_size is not set it will not be
      subsequently passed onto subordinate devices. This patch correctly
      populates pdata_size.
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      3c1534c7
    • S
      mfd: Arizone core should select MFD_CORE · c481c048
      Samuel Ortiz 提交于
      Otherwise, with:
      
      CONFIG_MFD_ARIZONA=y
      CONFIG_MFD_ARIZONA_I2C=m
      CONFIG_MFD_CORE=m
      
      We get:
      
      drivers/built-in.o: In function `arizona_dev_init':
      (.devinit.text+0x3ab0): undefined reference to `mfd_add_devices'
      drivers/built-in.o: In function `arizona_dev_init':
      (.devinit.text+0x3fdc): undefined reference to `mfd_add_devices'
      drivers/built-in.o: In function `arizona_dev_init':
      (.devinit.text+0x3fff): undefined reference to `mfd_add_devices'
      drivers/built-in.o: In function `arizona_dev_init':
      (.devinit.text+0x4059): undefined reference to `mfd_remove_devices'
      drivers/built-in.o: In function `arizona_dev_exit':
      (.devexit.text+0x9): undefined reference to `mfd_remove_devices'
      Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      c481c048
  6. 25 7月, 2012 8 次提交
  7. 23 7月, 2012 1 次提交
    • T
      pwm: Conflict with legacy PWM API · eac7a92f
      Thierry Reding 提交于
      In order to avoid duplicate symbols with legacy PWM API implementations,
      the new PWM framework needs to conflict with any of the existing legacy
      implementations. This is done in two ways: for implementations provided
      by drivers, a conflict is added to the driver to ensure it will have to
      be ported to the PWM subsystem before it can coexist with other PWM
      providers. For architecture-specific code, the conflict is added to the
      PWM symbol to avoid confusion when a previously picked platform or
      machine can no longer be selected because of the PWM subsystem being
      included.
      Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
      eac7a92f
  8. 19 7月, 2012 3 次提交
  9. 17 7月, 2012 1 次提交
  10. 16 7月, 2012 12 次提交