09 Sep, 2020

1 commit

  • SMBus Host-Notify protocol, from the adapter point of view
    consist of receiving a message from a client, including the
    client address and some other data.

    It can be simply handled by creating a new slave device
    and registering a callback performing the parsing of the
    message received from the client.

    This commit introduces two new core functions
    * i2c_new_slave_host_notify_device
    * i2c_free_slave_host_notify_device
    that take care of registration of the new slave device and
    callback and will call i2c_handle_smbus_host_notify once a
    Host-Notify event is received.

    Signed-off-by: Alain Volmat
    Reviewed-by: Pierre-Yves MORDRET
    Signed-off-by: Wolfram Sang

    Alain Volmat
     

29 May, 2020

1 commit


10 Mar, 2020

2 commits

  • IRQ levels are now handled within the IRQ core. Remove the forgotten
    references from the documentation.

    Fixes: 9b9f2b8bc2ac ("i2c: i2c-smbus: Use threaded irq for smbalert")
    Signed-off-by: Wolfram Sang
    Reviewed-by: Luca Ceresoli
    Signed-off-by: Wolfram Sang

    Wolfram Sang
     
  • Only few drivers use this call, so drivers and I2C core are converted at
    once with this patch. By simply using i2c_new_client_device() instead of
    i2c_new_device(), we easily can return an ERRPTR for this function as
    well. To make out of tree users aware that something changed, the
    function is renamed to i2c_new_smbus_alert_device().

    Signed-off-by: Wolfram Sang
    Reviewed-by: Luca Ceresoli
    Signed-off-by: Wolfram Sang

    Wolfram Sang
     

21 May, 2019

1 commit

  • Based on 2 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version this program is distributed in the
    hope that it will be useful but without any warranty without even
    the implied warranty of merchantability or fitness for a particular
    purpose see the gnu general public license for more details you
    should have received a copy of the gnu general public license along
    with this program if not write to the free software foundation inc
    51 franklin street fifth floor boston ma 02110 1301 usa

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option [no]_[pad]_[ctrl] any later version this program is
    distributed in the hope that it will be useful but without any
    warranty without even the implied warranty of merchantability or
    fitness for a particular purpose see the gnu general public license
    for more details you should have received a copy of the gnu general
    public license along with this program if not write to the free
    software foundation inc 51 franklin street fifth floor boston ma
    02110 1301 usa

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 176 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Jilayne Lovejoy
    Reviewed-by: Steve Winslow
    Reviewed-by: Allison Randal
    Reviewed-by: Kate Stewart
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190519154040.652910950@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

29 Oct, 2017

2 commits

  • This commit adds of_i2c_setup_smbus_alert which allows the smbalert
    driver to be attached to an i2c adapter via the device tree.

    Signed-off-by: Phil Reid
    Acked-by: Rob Herring
    Signed-off-by: Wolfram Sang

    Phil Reid
     
  • Prior to this commit the smbalert_irq was handling in the hard irq
    context. This change switch to using a thread irq which avoids the need
    for the work thread. Using threaded irq also removes the need for the
    edge_triggered flag as the enabling / disabling of the hard irq for level
    triggered interrupts will be handled by the irq core.

    Without this change have an irq connected to something like an i2c gpio
    resulted in a null ptr deferences. Specifically handle_nested_irq calls
    the threaded irq handler.

    There are currently 3 in tree drivers affected by this change.

    i2c-parport driver calls i2c_handle_smbus_alert in a hard irq context.
    This driver use edge trigger interrupts which skip the enable / disable
    calls. But it still need to handle the smbus transaction on a thread. So
    the work thread is kept for this driver.

    i2c-parport-light & i2c-thunderx-pcidrv provide the irq number in the
    setup which will result in the thread irq being used.

    i2c-parport-light is edge trigger so the enable / disable call was
    skipped as well.

    i2c-thunderx-pcidrv is getting the edge / level trigger setting from of
    data and was setting the flag as required. However the irq core should
    handle this automatically.

    Signed-off-by: Phil Reid
    Reviewed-by: Benjamin Tissoires
    Signed-off-by: Wolfram Sang

    Phil Reid
     

24 Nov, 2016

1 commit

  • The current SMBus Host Notify implementation relies on .alert() to
    relay its notifications. However, the use cases where SMBus Host
    Notify is needed currently is to signal data ready on touchpads.

    This is closer to an IRQ than a custom API through .alert().
    Given that the 2 touchpad manufacturers (Synaptics and Elan) that
    use SMBus Host Notify don't put any data in the SMBus payload, the
    concept actually matches one to one.

    Benefits are multiple:
    - simpler code and API: the client will just have an IRQ, and
    nothing needs to be added in the adapter beside internally
    enabling it.
    - no more specific workqueue, the threading is handled by IRQ core
    directly (when required)
    - no more races when removing the device (the drivers are already
    required to disable irq on remove)
    - simpler handling for drivers: use plain regular IRQs
    - no more dependency on i2c-smbus for i2c-i801 (and any other adapter)
    - the IRQ domain is created automatically when the adapter exports
    the Host Notify capability
    - the IRQ are assign only if ACPI, OF and the caller did not assign
    one already
    - the domain is automatically destroyed on remove
    - fewer lines of code (minus 20, yeah!)

    Signed-off-by: Benjamin Tissoires
    Signed-off-by: Wolfram Sang

    Benjamin Tissoires
     

22 Jul, 2016

1 commit


17 Jun, 2016

1 commit

  • SMBus Host Notify allows a slave device to act as a master on a bus to
    notify the host of an interrupt. On Intel chipsets, the functionality
    is directly implemented in the firmware. We just need to export a
    function to call .alert() on the proper device driver.

    i2c_handle_smbus_host_notify() behaves like i2c_handle_smbus_alert().
    When called, it schedules a task that will be able to sleep to go through
    the list of devices attached to the adapter.

    The current implementation allows one Host Notification to be scheduled
    while an other is running.

    Tested-by: Andrew Duggan
    Signed-off-by: Benjamin Tissoires
    Signed-off-by: Wolfram Sang

    Benjamin Tissoires
     

30 Jan, 2014

1 commit


27 Mar, 2012

1 commit


02 Mar, 2010

1 commit

  • SMBus alert support. The SMBus alert protocol allows several SMBus
    slave devices to share a single interrupt pin on the SMBus master,
    while still allowing the master to know which slave triggered the
    interrupt.

    This is based on preliminary work by David Brownell. The key
    difference between David's implementation and mine is that his was
    part of i2c-core, while mine is split into a separate, standalone
    module named i2c-smbus. The i2c-smbus module is meant to include
    support for all SMBus extensions to the I2C protocol in the future.

    The benefit of this approach is a zero cost for I2C bus segments which
    do not need SMBus alert support. Where David's implementation
    increased the size of struct i2c_adapter by 7% (40 bytes on i386),
    mine doesn't touch it. Where David's implementation added over 150
    lines of code to i2c-core (+10%), mine doesn't touch it. The only
    change that touches all the users of the i2c subsystem is a new
    callback in struct i2c_driver (common to both implementations.) I seem
    to remember Trent was worried about the footprint of David'd
    implementation, hopefully mine addresses the issue.

    Signed-off-by: Jean Delvare
    Acked-by: Jonathan Cameron
    Cc: David Brownell
    Cc: Trent Piepho

    Jean Delvare