1. 04 5月, 2019 1 次提交
  2. 06 4月, 2019 1 次提交
    • T
      i2c: of: Try to find an I2C adapter matching the parent · f0eb935c
      Thierry Reding 提交于
      [ Upstream commit e814e688413aabd7b0d75e2a8ed1caa472951dec ]
      
      If an I2C adapter doesn't match the provided device tree node, also try
      matching the parent's device tree node. This allows finding an adapter
      based on the device node of the parent device that was used to register
      it.
      
      This fixes a regression on Tegra124-based Chromebooks (Nyan) where the
      eDP controller registers an I2C adapter that is used to read to EDID.
      After commit 993a815dcbb2 ("dt-bindings: panel: Add missing .txt
      suffix") this stopped working because the I2C adapter could no longer
      be found. The approach in this patch fixes the regression without
      introducing the issues that the above commit solved.
      
      Fixes: 17ab7806 ("drm: don't link DP aux i2c adapter to the hardware device node")
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Tested-by: NTristan Bastian <tristan-c.bastian@gmx.de>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f0eb935c
  3. 24 3月, 2019 3 次提交
  4. 14 3月, 2019 1 次提交
    • T
      i2c: omap: Use noirq system sleep pm ops to idle device for suspend · ee84b62f
      Tony Lindgren 提交于
      [ Upstream commit c6e2bd956936d925748581e4d0294f10f1d92f2c ]
      
      We currently get the following error with pixcir_ts driver during a
      suspend resume cycle:
      
      omap_i2c 4802a000.i2c: controller timed out
      pixcir_ts 1-005c: pixcir_int_enable: can't read reg 0x34 : -110
      pixcir_ts 1-005c: Failed to disable interrupt generation: -110
      pixcir_ts 1-005c: Failed to stop
      dpm_run_callback(): pixcir_i2c_ts_resume+0x0/0x98
      [pixcir_i2c_ts] returns -110
      PM: Device 1-005c failed to resume: error -110
      
      And at least am437x based devices with pixcir_ts will fail to resume
      to a touchscreen that is configured as the wakeup-source in device
      tree for these devices.
      
      This is because pixcir_ts tries to reconfigure it's registers for
      noirq suspend which fails. This also leaves i2c-omap in enabled state
      for suspend.
      
      Let's fix the pixcir_ts issue and make sure i2c-omap is suspended by
      adding SET_NOIRQ_SYSTEM_SLEEP_PM_OPS.
      
      Let's also get rid of some ifdefs while at it and replace them with
      __maybe_unused as SET_RUNTIME_PM_OPS and SET_NOIRQ_SYSTEM_SLEEP_PM_OPS
      already deal with the various PM Kconfig options.
      Reported-by: NKeerthy <j-keerthy@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NVignesh R <vigneshr@ti.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ee84b62f
  5. 13 2月, 2019 3 次提交
  6. 17 1月, 2019 1 次提交
    • Y
      i2c: dev: prevent adapter retries and timeout being set as minus value · fca4eb31
      Yi Zeng 提交于
      commit 6ebec961d59bccf65d08b13fc1ad4e6272a89338 upstream.
      
      If adapter->retries is set to a minus value from user space via ioctl,
      it will make __i2c_transfer and __i2c_smbus_xfer skip the calling to
      adapter->algo->master_xfer and adapter->algo->smbus_xfer that is
      registered by the underlying bus drivers, and return value 0 to all the
      callers. The bus driver will never be accessed anymore by all users,
      besides, the users may still get successful return value without any
      error or information log print out.
      
      If adapter->timeout is set to minus value from user space via ioctl,
      it will make the retrying loop in __i2c_transfer and __i2c_smbus_xfer
      always break after the the first try, due to the time_after always
      returns true.
      Signed-off-by: NYi Zeng <yizeng@asrmicro.com>
      [wsa: minor grammar updates to commit message]
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fca4eb31
  7. 21 12月, 2018 5 次提交
    • M
      i2c: uniphier-f: fix violation of tLOW requirement for Fast-mode · cab9d276
      Masahiro Yamada 提交于
      [ Upstream commit ece27a337d42a3197935711997f2880f0957ed7e ]
      
      Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode,
      tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us.
      
      tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode:
        Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us
        Fast-mode:     tLOW = 1.39 us, tHIGH = 1.11 us
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cab9d276
    • M
      i2c: uniphier: fix violation of tLOW requirement for Fast-mode · eb296b2d
      Masahiro Yamada 提交于
      [ Upstream commit 8469636ab5d8c77645b953746c10fda6983a8830 ]
      
      Currently, the clock duty is set as tLOW/tHIGH = 1/1. For Fast-mode,
      tLOW is set to 1.25 us while the I2C spec requires tLOW >= 1.3 us.
      
      tLOW/tHIGH = 5/4 would meet both Standard-mode and Fast-mode:
        Standard-mode: tLOW = 5.56 us, tHIGH = 4.44 us
        Fast-mode:     tLOW = 1.39 us, tHIGH = 1.11 us
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      eb296b2d
    • H
      i2c: scmi: Fix probe error on devices with an empty SMB0001 ACPI device node · 9d5db5be
      Hans de Goede 提交于
      [ Upstream commit 0544ee4b1ad574aec3b6379af5f5cdee42840971 ]
      
      Some AMD based HP laptops have a SMB0001 ACPI device node which does not
      define any methods.
      
      This leads to the following error in dmesg:
      
      [    5.222731] cmi: probe of SMB0001:00 failed with error -5
      
      This commit makes acpi_smbus_cmi_add() return -ENODEV instead in this case
      silencing the error. In case of a failure of the i2c_add_adapter() call
      this commit now propagates the error from that call instead of -EIO.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9d5db5be
    • A
      i2c: axxia: properly handle master timeout · 9be9c23a
      Adamski, Krzysztof (Nokia - PL/Wroclaw) 提交于
      [ Upstream commit 6c7f25cae54b840302e4f1b371dbf318fbf09ab2 ]
      
      According to Intel (R) Axxia TM Lionfish Communication Processor
      Peripheral Subsystem Hardware Reference Manual, the AXXIA I2C module
      have a programmable Master Wait Timer, which among others, checks the
      time between commands send in manual mode. When a timeout (25ms) passes,
      TSS bit is set in Master Interrupt Status register and a Stop command is
      issued by the hardware.
      
      The axxia_i2c_xfer(), does not properly handle this situation, however.
      For each message a separate axxia_i2c_xfer_msg() is called and this
      function incorrectly assumes that any interrupt might happen only when
      waiting for completion. This is mostly correct but there is one
      exception - a master timeout can trigger if enough time has passed
      between individual transfers. It will, by definition, happen between
      transfers when the interrupts are disabled by the code. If that happens,
      the hardware issues Stop command.
      
      The interrupt indicating timeout will not be triggered as soon as we
      enable them since the Master Interrupt Status is cleared when master
      mode is entered again (which happens before enabling irqs) meaning this
      error is lost and the transfer is continued even though the Stop was
      issued on the bus. The subsequent operations completes without error but
      a bogus value (0xFF in case of read) is read as the client device is
      confused because aborted transfer. No error is returned from
      master_xfer() making caller believe that a valid value was read.
      
      To fix the problem, the TSS bit (indicating timeout) in Master Interrupt
      Status register is checked before each transfer. If it is set, there was
      a timeout before this transfer and (as described above) the hardware
      already issued Stop command so the transaction should be aborted thus
      -ETIMEOUT is returned from the master_xfer() callback. In order to be
      sure no timeout was issued we can't just read the status just before
      starting new transaction as there will always be a small window of time
      (few CPU cycles at best) where this might still happen. For this reason
      we have to temporally disable the timer before checking for TSS bit.
      Disabling it will, however, clear the TSS bit so in order to preserve
      that information, we have to read it in ISR so we have to ensure that
      the TSS interrupt is not masked between transfers of one transaction.
      There is no need to call bus recovery or controller reinitialization if
      that happens so it's skipped.
      Signed-off-by: NKrzysztof Adamski <krzysztof.adamski@nokia.com>
      Reviewed-by: NAlexander Sverdlin <alexander.sverdlin@nokia.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9be9c23a
    • W
      i2c: rcar: check bus state before reinitializing · b288daf8
      Wolfram Sang 提交于
      [ Upstream commit 0b57436f ]
      
      We should check the bus state before reinitializing the IP core.
      Otherwise, the internal bus busy state which also tracks multi-master
      activity is lost.
      
      Credits go to the Renesas BSP team for suggesting this change.
      Reported-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Fixes: ae481cc1 ("i2c: rcar: fix resume by always initializing registers before transfer")
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b288daf8
  8. 20 12月, 2018 1 次提交
    • A
      i2c: aspeed: fix build warning · cd50eeeb
      Arnd Bergmann 提交于
      Upstream commit 3e9efc3299dd ("i2c: aspeed: Handle master/slave combined irq events
      properly") reworked the interrupt handling and fixed a warning in the process:
      
      drivers/i2c/busses/i2c-aspeed.c: In function 'aspeed_i2c_bus_irq':
      drivers/i2c/busses/i2c-aspeed.c:567:1: error: label 'out' defined but not used [-Werror=unused-label]
      
      The warning is still present in v4.19.8 and can be fixed either by applying
      that original patch, or by adding a simple #ifdef.
      
      Here, I choose the second simpler option as the original patch seems too
      invasive for a stable backport.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NBrendan Higgins <brendanhiggins@google.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cd50eeeb
  9. 27 11月, 2018 2 次提交
  10. 20 10月, 2018 1 次提交
  11. 12 10月, 2018 1 次提交
  12. 05 10月, 2018 1 次提交
  13. 01 10月, 2018 1 次提交
    • E
      i2c: i2c-scmi: fix for i2c_smbus_write_block_data · 08d9db00
      Edgar Cherkasov 提交于
      The i2c-scmi driver crashes when the SMBus Write Block transaction is
      executed:
      
      WARNING: CPU: 9 PID: 2194 at mm/page_alloc.c:3931 __alloc_pages_slowpath+0x9db/0xec0
       Call Trace:
        ? get_page_from_freelist+0x49d/0x11f0
        ? alloc_pages_current+0x6a/0xe0
        ? new_slab+0x499/0x690
        __alloc_pages_nodemask+0x265/0x280
        alloc_pages_current+0x6a/0xe0
        kmalloc_order+0x18/0x40
        kmalloc_order_trace+0x24/0xb0
        ? acpi_ut_allocate_object_desc_dbg+0x62/0x10c
        __kmalloc+0x203/0x220
        acpi_os_allocate_zeroed+0x34/0x36
        acpi_ut_copy_eobject_to_iobject+0x266/0x31e
        acpi_evaluate_object+0x166/0x3b2
        acpi_smbus_cmi_access+0x144/0x530 [i2c_scmi]
        i2c_smbus_xfer+0xda/0x370
        i2cdev_ioctl_smbus+0x1bd/0x270
        i2cdev_ioctl+0xaa/0x250
        do_vfs_ioctl+0xa4/0x600
        SyS_ioctl+0x79/0x90
        do_syscall_64+0x73/0x130
        entry_SYSCALL_64_after_hwframe+0x3d/0xa2
      ACPI Error: Evaluating _SBW: 4 (20170831/smbus_cmi-185)
      
      This problem occurs because the length of ACPI Buffer object is not
      defined/initialized in the code before a corresponding ACPI method is
      called. The obvious patch below fixes this issue.
      Signed-off-by: NEdgar Cherkasov <echerkasov@dev.rtsoft.ru>
      Acked-by: NViktor Krasnov <vkrasnov@dev.rtsoft.ru>
      Acked-by: NMichael Brunner <Michael.Brunner@kontron.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      08d9db00
  14. 25 9月, 2018 2 次提交
  15. 07 9月, 2018 1 次提交
  16. 05 9月, 2018 1 次提交
  17. 03 9月, 2018 3 次提交
  18. 31 8月, 2018 6 次提交
    • W
      i2c: sh_mobile: fix leak when using DMA bounce buffer · cebc07d8
      Wolfram Sang 提交于
      We only freed the bounce buffer after successful DMA, missing the cases
      where DMA setup may have gone wrong. Use a better location which always
      gets called after each message and use 'stop_after_dma' as a flag for a
      successful transfer.
      Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      cebc07d8
    • W
      i2c: sh_mobile: define start_ch() void as it only returns 0 anyhow · 531db501
      Wolfram Sang 提交于
      After various refactoring over the years, start_ch() doesn't return
      errno anymore, so make the function return void. This saves the error
      handling when calling it which in turn eases cleanup of resources of a
      future patch.
      Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      531db501
    • W
      i2c: refactor function to release a DMA safe buffer · 82fe39a6
      Wolfram Sang 提交于
      a) rename to 'put' instead of 'release' to match 'get' when obtaining
         the buffer
      b) change the argument order to have the buffer as first argument
      c) add a new argument telling the function if the message was
         transferred. This allows the function to be used also in cases
         where setting up DMA failed, so the buffer needs to be freed without
         syncing to the message buffer.
      
      Also convert the only user.
      Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Reviewed-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      82fe39a6
    • J
      i2c: algos: bit: make the error messages grepable · 1204d12a
      Jan Kundrát 提交于
      Yep, I went looking for one of these, and I wasn't able to find it
      easily.  That's worse than a line which is 82-chars long, IMHO.
      Signed-off-by: NJan Kundrát <jan.kundrat@cesnet.cz>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      1204d12a
    • H
      i2c: designware: Re-init controllers with pm_disabled set on resume · 9d9a152e
      Hans de Goede 提交于
      On Bay Trail and Cherry Trail devices we set the pm_disabled flag for I2C
      busses which the OS shares with the PUNIT as these need special handling.
      Until now we called dev_pm_syscore_device(dev, true) for I2C controllers
      with this flag set to keep these I2C controllers always on.
      
      After commit 12864ff8 ("ACPI / LPSS: Avoid PM quirks on suspend and
      resume from hibernation"), this no longer works. This commit modifies
      lpss_iosf_exit_d3_state() to only run if lpss_iosf_enter_d3_state() has ran
      before it, so that it does not run on a resume from hibernate (or from S3).
      
      On these systems the conditions for lpss_iosf_enter_d3_state() to run
      never become true, so lpss_iosf_exit_d3_state() never gets called and
      the 2 LPSS DMA controllers never get forced into D0 mode, instead they
      are left in their default automatic power-on when needed mode.
      
      The not forcing of D0 mode for the DMA controllers enables these systems
      to properly enter S0ix modes, which is a good thing.
      
      But after entering S0ix modes the I2C controller connected to the PMIC
      no longer works, leading to e.g. broken battery monitoring.
      
      The _PS3 method for this I2C controller looks like this:
      
                  Method (_PS3, 0, NotSerialized)  // _PS3: Power State 3
                  {
                      If ((((PMID == 0x04) || (PMID == 0x05)) || (PMID == 0x06)))
                      {
                          Return (Zero)
                      }
      
                      PSAT |= 0x03
                      Local0 = PSAT /* \_SB_.I2C5.PSAT */
                  }
      
      Where PMID = 0x05, so we enter the Return (Zero) path on these systems.
      
      So even if we were to not call dev_pm_syscore_device(dev, true) the
      I2C controller will be left in D0 rather then be switched to D3.
      
      Yet on other Bay and Cherry Trail devices S0ix is not entered unless *all*
      I2C controllers are in D3 mode. This combined with the I2C controller no
      longer working now that we reach S0ix states on these systems leads to me
      believing that the PUNIT itself puts the I2C controller in D3 when all
      other conditions for entering S0ix states are true.
      
      Since now the I2C controller is put in D3 over a suspend/resume we must
      re-initialize it afterwards and that does indeed fix it no longer working.
      
      This commit implements this fix by:
      
      1) Making the suspend_late callback a no-op if pm_disabled is set and
      making the resume_early callback skip the clock re-enable (since it now was
      not disabled) while still doing the necessary I2C controller re-init.
      
      2) Removing the dev_pm_syscore_device(dev, true) call, so that the suspend
      and resume callbacks are actually called. Normally this would cause the
      ACPI pm code to call _PS3 putting the I2C controller in D3, wreaking havoc
      since it is shared with the PUNIT, but in this special case the _PS3 method
      is a no-op so we can safely allow a "fake" suspend / resume.
      
      Fixes: 12864ff8 ("ACPI / LPSS: Avoid PM quirks on suspend and resume ...")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=200861
      Cc: 4.15+ <stable@vger.kernel.org> # 4.15+
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      9d9a152e
    • M
      i2c: i801: Allow ACPI AML access I/O ports not reserved for SMBus · 7fd6d98b
      Mika Westerberg 提交于
      Commit 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict
      with PCI BAR") made it possible for AML code to access SMBus I/O ports
      by installing custom SystemIO OpRegion handler and blocking i80i driver
      access upon first AML read/write to this OpRegion.
      
      However, while ThinkPad T560 does have SystemIO OpRegion declared under
      the SMBus device, it does not access any of the SMBus registers:
      
          Device (SMBU)
          {
              ...
      
              OperationRegion (SMBP, PCI_Config, 0x50, 0x04)
              Field (SMBP, DWordAcc, NoLock, Preserve)
              {
                  ,   5,
                  TCOB,   11,
                  Offset (0x04)
              }
      
              Name (TCBV, 0x00)
              Method (TCBS, 0, NotSerialized)
              {
                  If ((TCBV == 0x00))
                  {
                  TCBV = (\_SB.PCI0.SMBU.TCOB << 0x05)
                  }
      
                  Return (TCBV) /* \_SB_.PCI0.SMBU.TCBV */
              }
      
              OperationRegion (TCBA, SystemIO, TCBS (), 0x10)
              Field (TCBA, ByteAcc, NoLock, Preserve)
              {
                  Offset (0x04),
                  ,   9,
                  CPSC,   1
              }
          }
      
      Problem with the current approach is that it blocks all I/O port access
      and because this system has touchpad connected to the SMBus controller
      after first AML access (happens during suspend/resume cycle) the
      touchpad fails to work anymore.
      
      Fix this so that we allow ACPI AML I/O port access if it does not touch
      the region reserved for the SMBus.
      
      Fixes: 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=200737Reported-by: NYussuf Khalil <dev@pp3345.net>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NJean Delvare <jdelvare@suse.de>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      7fd6d98b
  19. 24 8月, 2018 4 次提交
  20. 20 8月, 2018 1 次提交