Eric Lee / smarc-fsl-linux-kernel

04 Dec, 2018

3 commits

20 Aug, 2018

2 commits

  • 0a30446c0   i2c: core: ACPI: Make acpi_gsb_i2c_read_bytes() check i2c_transfer return value ... Browse Code »

    Currently acpi_gsb_i2c_read_bytes() directly returns i2c_transfer's return
    value. i2c_transfer returns a value < 0 on error and 2 (for 2 successfully
    executed transfers) on success. But the ACPI code expects 0 on success, so
    currently acpi_gsb_i2c_read_bytes()'s caller does:

    if (status > 0)
    status = 0;

    This commit makes acpi_gsb_i2c_read_bytes() return a value which can be
    directly consumed by the ACPI code, mirroring acpi_gsb_i2c_write_bytes(),
    this commit also makes acpi_gsb_i2c_read_bytes() explitcly check that
    i2c_transfer returns 2, rather then accepting any value > 0.

    Signed-off-by: Hans de Goede
    Acked-by: Mika Westerberg
    Signed-off-by: Wolfram Sang

    Hans de Goede
     
  • c463a158c   i2c: core: ACPI: Properly set status byte to 0 for multi-byte writes ... Browse Code »

    acpi_gsb_i2c_write_bytes() returns i2c_transfer()'s return value, which
    is the number of transfers executed on success, so 1.

    The ACPI code expects us to store 0 in gsb->status for success, not 1.

    Specifically this breaks the following code in the Thinkpad 8 DSDT:

    ECWR = I2CW = ECWR /* \_SB_.I2C1.BAT0.ECWR */
    If ((ECST == Zero))
    {
    ECRD = I2CR /* \_SB_.I2C1.I2CR */
    }

    Before this commit we set ECST to 1, causing the read to never happen
    breaking battery monitoring on the Thinkpad 8.

    This commit makes acpi_gsb_i2c_write_bytes() return 0 when i2c_transfer()
    returns 1, so the single write transfer completed successfully, and
    makes it return -EIO on for other (unexpected) return values >= 0.

    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede
    Acked-by: Mika Westerberg
    Signed-off-by: Wolfram Sang

    Hans de Goede
     

30 Apr, 2018

2 commits

  • 7781edaed   i2c: core: ACPI: Log device not acking errors at dbg loglevel ... Browse Code »

    Unfortunately some DSDTs issue bogus i2c reads to non existing devices
    resulting in -EREMOTEIO errors because the non existing device of course
    does not ack.

    This happens e.g. from the The Asus T100TA's _BIX method, the DSDT on
    the T100TA defines 2 resources on the I2C1 bus:

    Name (EHID, ResourceTemplate ()
    {
    I2cSerialBusV2 (0x005B, ControllerInitiated, 0x00061A80,
    AddressingMode7Bit, "\\_SB.I2C1",
    0x00, ResourceConsumer, , Exclusive,
    )
    })
    OperationRegion (EHOR, GenericSerialBus, Zero, 0x0100)
    Field (EHOR, BufferAcc, NoLock, Preserve)
    {
    Connection (EHID),
    Offset (0x01),
    AccessAs (BufferAcc, AttribBytes (0x10)),
    ABCD, 8
    }

    Name (UMPC, ResourceTemplate ()
    {
    I2cSerialBusV2 (0x0066, ControllerInitiated, 0x00061A80,
    AddressingMode7Bit, "\\_SB.I2C1",
    0x00, ResourceConsumer, , Exclusive,
    )
    })

    The _BIX method does a single read (on each BIX() call) from the EHID
    device through the ABCD Field, only to completely ignore the result.
    This read always fails as there is no i2c client at address 0x5b.

    The _BIX method also does several reads from the UMPC device and actually
    uses the results of those to provide battery information.

    IIRC I've also seen some DSTDs which do an i2c read to detect if a device
    is present, also leading to false positive errors being logged.

    Esp. the _BIX use is problematic as the _BIX method gets called
    periodically to monitor battery status.

    This commit stops the logs from filling up with errors like these:

    [ 57.327858] i2c i2c-0: i2c read 16 bytes from client@0x5b starting at
    reg 0x1 failed, error: -121

    Signed-off-by: Hans de Goede
    Reviewed-by: Mika Westerberg
    Signed-off-by: Wolfram Sang

    Hans de Goede
     
  • c8016fa21   i2c: core: ACPI: Improve OpRegion read errors ... Browse Code »

    When we get an error doing an ACPI SerialBus I2C OpRegion read log some
    useful details, like the client address and which register is being
    read.

    Signed-off-by: Hans de Goede
    Reviewed-by: Mika Westerberg
    Signed-off-by: Wolfram Sang

    Hans de Goede
     

31 Jul, 2017

1 commit

  • c64ffff7a   i2c: core: Allow empty id_table in ACPI case as well ... Browse Code »

    For now empty ID table is not allowed with ACPI and prevents driver to
    be probed.

    Add a check to allow empty ID table.

    This introduces a helper i2c_acpi_match_device().

    Note, we rename some static function in i2c-core-acpi.c to distinguish
    with public API.

    Fixes: da10c06a044b ("i2c: Make I2C ID tables non-mandatory for DT'ed devices")
    Signed-off-by: Andy Shevchenko
    Tested-by: Rajmohan Mani
    Acked-by: Mika Westerberg
    [wsa: needed to get some drivers probed again]
    Signed-off-by: Wolfram Sang

    Andy Shevchenko
     

04 Jul, 2017

1 commit

  • 3a4991a98   i2c: acpi: Do not create i2c-clients for LNXVIDEO ACPI devices ... Browse Code »

    ACPI video devices get tagged by the kernel with the custom LNXVIDEO
    HID so that normal pnp-id matching can be used and are handled by the
    acpi-video driver.

    Sometimes the ACPI nodes describing these contain a SERIAL_TYPE_I2C ACPI
    resource. Before this commit the presence of this resource would cause the
    i2c-core to create a /sys/bus/i2c/devices/i2c-LNXVIDEO:00 device for this
    with a modalias of: "i2c:LNXVIDEO:00".

    There is no i2c driver for this custom HID, the acpi-video driver binds
    directly to the ACPI device /sys/bus/acpi/devices/LNXVIDEO\:00 which has
    a modalias of "acpi:LNXVIDEO:" .

    Not only is the creation of an i2c-client for this undesirable, it is
    actually causing problems. This weird pseudo-resource claims an i2c
    speed of 100KHz and typically points to the i2c bus which is used by the
    touchscreen controller. Some touchscreen controllers only work properly at
    400KHz, at 100KHz they cause errors like these:

    i2c_designware 80860F41:03: i2c_dw_handle_tx_abort: lost arbitration
    i2c_designware 80860F41:03: i2c_dw_handle_tx_abort: lost arbitration
    i2c_designware 80860F41:03: i2c_dw_handle_tx_abort: lost arbitration
    i2c_designware 80860F41:03: i2c_dw_handle_tx_abort: lost arbitration
    silead_ts i2c-MSSL1680:00: Registers clear error -11

    This commit makes the i2c-core ignore LNXVIDEO compatible ACPI devices
    which has 2 positive results:

    1) The bogus i2c-client for these is no longer created.
    2) i2c_acpi_lookup_speed now ignores the 100KHz speed from the pseudo
    i2c-resouce and properly returns 400KHz as speed for the touchscreen
    i2c bus, fixing the touchscreen not working on various devies.

    Signed-off-by: Hans de Goede
    Reviewed-by: Andy Shevchenko
    Signed-off-by: Wolfram Sang

    Hans de Goede
     

01 Jun, 2017

1 commit