OpenCloudOS-Kernel/drivers/i2c/i2c-core-acpi.c

825 lines
20 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-or-later
/*
* Linux I2C core ACPI support code
*
* Copyright (C) 2014 Intel Corp, Author: Lan Tianyu <tianyu.lan@intel.com>
*/
#include <linux/acpi.h>
#include <linux/device.h>
#include <linux/err.h>
#include <linux/i2c.h>
#include <linux/list.h>
#include <linux/module.h>
#include <linux/slab.h>
#include "i2c-core.h"
struct i2c_acpi_handler_data {
struct acpi_connection_info info;
struct i2c_adapter *adapter;
};
struct gsb_buffer {
u8 status;
u8 len;
union {
u16 wdata;
u8 bdata;
DECLARE_FLEX_ARRAY(u8, data);
};
} __packed;
struct i2c_acpi_lookup {
struct i2c_board_info *info;
acpi_handle adapter_handle;
acpi_handle device_handle;
acpi_handle search_handle;
int n;
int index;
u32 speed;
u32 min_speed;
u32 force_speed;
};
/**
* i2c_acpi_get_i2c_resource - Gets I2cSerialBus resource if type matches
* @ares: ACPI resource
* @i2c: Pointer to I2cSerialBus resource will be returned here
*
* Checks if the given ACPI resource is of type I2cSerialBus.
* In this case, returns a pointer to it to the caller.
*
* Returns true if resource type is of I2cSerialBus, otherwise false.
*/
bool i2c_acpi_get_i2c_resource(struct acpi_resource *ares,
struct acpi_resource_i2c_serialbus **i2c)
{
struct acpi_resource_i2c_serialbus *sb;
if (ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
return false;
sb = &ares->data.i2c_serial_bus;
if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C)
return false;
*i2c = sb;
return true;
}
EXPORT_SYMBOL_GPL(i2c_acpi_get_i2c_resource);
static int i2c_acpi_resource_count(struct acpi_resource *ares, void *data)
{
struct acpi_resource_i2c_serialbus *sb;
int *count = data;
if (i2c_acpi_get_i2c_resource(ares, &sb))
*count = *count + 1;
return 1;
}
/**
* i2c_acpi_client_count - Count the number of I2cSerialBus resources
* @adev: ACPI device
*
* Returns the number of I2cSerialBus resources in the ACPI-device's
* resource-list; or a negative error code.
*/
int i2c_acpi_client_count(struct acpi_device *adev)
{
int ret, count = 0;
LIST_HEAD(r);
ret = acpi_dev_get_resources(adev, &r, i2c_acpi_resource_count, &count);
if (ret < 0)
return ret;
acpi_dev_free_resource_list(&r);
return count;
}
EXPORT_SYMBOL_GPL(i2c_acpi_client_count);
static int i2c_acpi_fill_info(struct acpi_resource *ares, void *data)
{
struct i2c_acpi_lookup *lookup = data;
struct i2c_board_info *info = lookup->info;
struct acpi_resource_i2c_serialbus *sb;
acpi_status status;
if (info->addr || !i2c_acpi_get_i2c_resource(ares, &sb))
return 1;
if (lookup->index != -1 && lookup->n++ != lookup->index)
return 1;
status = acpi_get_handle(lookup->device_handle,
sb->resource_source.string_ptr,
&lookup->adapter_handle);
if (ACPI_FAILURE(status))
return 1;
info->addr = sb->slave_address;
lookup->speed = sb->connection_speed;
if (sb->access_mode == ACPI_I2C_10BIT_MODE)
info->flags |= I2C_CLIENT_TEN;
return 1;
}
i2c: acpi: Do not create i2c-clients for LNXVIDEO ACPI devices 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 <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2017-07-04 21:04:48 +08:00
static const struct acpi_device_id i2c_acpi_ignored_device_ids[] = {
/*
* ACPI video acpi_devices, which are handled by the acpi-video driver
* sometimes contain a SERIAL_TYPE_I2C ACPI resource, ignore these.
*/
{ ACPI_VIDEO_HID, 0 },
{}
};
struct i2c_acpi_irq_context {
int irq;
bool wake_capable;
};
static int i2c_acpi_do_lookup(struct acpi_device *adev,
struct i2c_acpi_lookup *lookup)
{
struct i2c_board_info *info = lookup->info;
struct list_head resource_list;
int ret;
if (acpi_bus_get_status(adev))
return -EINVAL;
if (!acpi_dev_ready_for_enumeration(adev))
return -ENODEV;
i2c: acpi: Do not create i2c-clients for LNXVIDEO ACPI devices 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 <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2017-07-04 21:04:48 +08:00
if (acpi_match_device_ids(adev, i2c_acpi_ignored_device_ids) == 0)
return -ENODEV;
memset(info, 0, sizeof(*info));
lookup->device_handle = acpi_device_handle(adev);
/* Look up for I2cSerialBus resource */
INIT_LIST_HEAD(&resource_list);
ret = acpi_dev_get_resources(adev, &resource_list,
i2c_acpi_fill_info, lookup);
acpi_dev_free_resource_list(&resource_list);
if (ret < 0 || !info->addr)
return -EINVAL;
return 0;
}
static int i2c_acpi_add_irq_resource(struct acpi_resource *ares, void *data)
{
struct i2c_acpi_irq_context *irq_ctx = data;
struct resource r;
if (irq_ctx->irq > 0)
return 1;
if (!acpi_dev_resource_interrupt(ares, 0, &r))
return 1;
irq_ctx->irq = i2c_dev_irq_from_resources(&r, 1);
irq_ctx->wake_capable = r.flags & IORESOURCE_IRQ_WAKECAPABLE;
return 1; /* No need to add resource to the list */
}
/**
* i2c_acpi_get_irq - get device IRQ number from ACPI
* @client: Pointer to the I2C client device
* @wake_capable: Set to true if the IRQ is wake capable
*
* Find the IRQ number used by a specific client device.
*
* Return: The IRQ number or an error code.
*/
int i2c_acpi_get_irq(struct i2c_client *client, bool *wake_capable)
{
struct acpi_device *adev = ACPI_COMPANION(&client->dev);
struct list_head resource_list;
struct i2c_acpi_irq_context irq_ctx = {
.irq = -ENOENT,
};
int ret;
INIT_LIST_HEAD(&resource_list);
ret = acpi_dev_get_resources(adev, &resource_list,
i2c_acpi_add_irq_resource, &irq_ctx);
if (ret < 0)
return ret;
acpi_dev_free_resource_list(&resource_list);
if (irq_ctx.irq == -ENOENT)
irq_ctx.irq = acpi_dev_gpio_irq_wake_get(adev, 0, &irq_ctx.wake_capable);
if (irq_ctx.irq < 0)
return irq_ctx.irq;
if (wake_capable)
*wake_capable = irq_ctx.wake_capable;
return irq_ctx.irq;
}
static int i2c_acpi_get_info(struct acpi_device *adev,
struct i2c_board_info *info,
struct i2c_adapter *adapter,
acpi_handle *adapter_handle)
{
struct i2c_acpi_lookup lookup;
int ret;
memset(&lookup, 0, sizeof(lookup));
lookup.info = info;
lookup.index = -1;
if (acpi_device_enumerated(adev))
return -EINVAL;
ret = i2c_acpi_do_lookup(adev, &lookup);
if (ret)
return ret;
if (adapter) {
/* The adapter must match the one in I2cSerialBus() connector */
if (ACPI_HANDLE(&adapter->dev) != lookup.adapter_handle)
return -ENODEV;
} else {
struct acpi_device *adapter_adev;
/* The adapter must be present */
adapter_adev = acpi_fetch_acpi_dev(lookup.adapter_handle);
if (!adapter_adev)
return -ENODEV;
if (acpi_bus_get_status(adapter_adev) ||
!adapter_adev->status.present)
return -ENODEV;
}
info->fwnode = acpi_fwnode_handle(adev);
if (adapter_handle)
*adapter_handle = lookup.adapter_handle;
acpi_set_modalias(adev, dev_name(&adev->dev), info->type,
sizeof(info->type));
return 0;
}
static void i2c_acpi_register_device(struct i2c_adapter *adapter,
struct acpi_device *adev,
struct i2c_board_info *info)
{
/*
* Skip registration on boards where the ACPI tables are
* known to contain bogus I2C devices.
*/
if (acpi_quirk_skip_i2c_client_enumeration(adev))
return;
adev->power.flags.ignore_parent = true;
acpi_device_set_enumerated(adev);
if (IS_ERR(i2c_new_client_device(adapter, info)))
adev->power.flags.ignore_parent = false;
}
static acpi_status i2c_acpi_add_device(acpi_handle handle, u32 level,
void *data, void **return_value)
{
struct i2c_adapter *adapter = data;
struct acpi_device *adev = acpi_fetch_acpi_dev(handle);
struct i2c_board_info info;
if (!adev || i2c_acpi_get_info(adev, &info, adapter, NULL))
return AE_OK;
i2c_acpi_register_device(adapter, adev, &info);
return AE_OK;
}
#define I2C_ACPI_MAX_SCAN_DEPTH 32
/**
* i2c_acpi_register_devices - enumerate I2C slave devices behind adapter
* @adap: pointer to adapter
*
* Enumerate all I2C slave devices behind this adapter by walking the ACPI
* namespace. When a device is found it will be added to the Linux device
* model and bound to the corresponding ACPI handle.
*/
void i2c_acpi_register_devices(struct i2c_adapter *adap)
{
struct acpi_device *adev;
acpi_status status;
if (!has_acpi_companion(&adap->dev))
return;
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
I2C_ACPI_MAX_SCAN_DEPTH,
i2c_acpi_add_device, NULL,
adap, NULL);
if (ACPI_FAILURE(status))
dev_warn(&adap->dev, "failed to enumerate I2C slaves\n");
if (!adap->dev.parent)
return;
adev = ACPI_COMPANION(adap->dev.parent);
if (!adev)
return;
acpi_dev_clear_dependencies(adev);
}
static const struct acpi_device_id i2c_acpi_force_400khz_device_ids[] = {
/*
* These Silead touchscreen controllers only work at 400KHz, for
* some reason they do not work at 100KHz. On some devices the ACPI
* tables list another device at their bus as only being capable
* of 100KHz, testing has shown that these other devices work fine
* at 400KHz (as can be expected of any recent i2c hw) so we force
* the speed of the bus to 400 KHz if a Silead device is present.
*/
{ "MSSL1680", 0 },
{}
};
static acpi_status i2c_acpi_lookup_speed(acpi_handle handle, u32 level,
void *data, void **return_value)
{
struct i2c_acpi_lookup *lookup = data;
struct acpi_device *adev = acpi_fetch_acpi_dev(handle);
if (!adev || i2c_acpi_do_lookup(adev, lookup))
return AE_OK;
if (lookup->search_handle != lookup->adapter_handle)
return AE_OK;
if (lookup->speed <= lookup->min_speed)
lookup->min_speed = lookup->speed;
if (acpi_match_device_ids(adev, i2c_acpi_force_400khz_device_ids) == 0)
lookup->force_speed = I2C_MAX_FAST_MODE_FREQ;
return AE_OK;
}
/**
* i2c_acpi_find_bus_speed - find I2C bus speed from ACPI
* @dev: The device owning the bus
*
* Find the I2C bus speed by walking the ACPI namespace for all I2C slaves
* devices connected to this bus and use the speed of slowest device.
*
* Returns the speed in Hz or zero
*/
u32 i2c_acpi_find_bus_speed(struct device *dev)
{
struct i2c_acpi_lookup lookup;
struct i2c_board_info dummy;
acpi_status status;
if (!has_acpi_companion(dev))
return 0;
memset(&lookup, 0, sizeof(lookup));
lookup.search_handle = ACPI_HANDLE(dev);
lookup.min_speed = UINT_MAX;
lookup.info = &dummy;
lookup.index = -1;
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
I2C_ACPI_MAX_SCAN_DEPTH,
i2c_acpi_lookup_speed, NULL,
&lookup, NULL);
if (ACPI_FAILURE(status)) {
dev_warn(dev, "unable to find I2C bus speed from ACPI\n");
return 0;
}
if (lookup.force_speed) {
if (lookup.force_speed != lookup.min_speed)
dev_warn(dev, FW_BUG "DSDT uses known not-working I2C bus speed %d, forcing it to %d\n",
lookup.min_speed, lookup.force_speed);
return lookup.force_speed;
} else if (lookup.min_speed != UINT_MAX) {
return lookup.min_speed;
} else {
return 0;
}
}
EXPORT_SYMBOL_GPL(i2c_acpi_find_bus_speed);
struct i2c_adapter *i2c_acpi_find_adapter_by_handle(acpi_handle handle)
{
struct i2c_adapter *adapter;
struct device *dev;
dev = bus_find_device(&i2c_bus_type, NULL, handle, device_match_acpi_handle);
if (!dev)
return NULL;
adapter = i2c_verify_adapter(dev);
if (!adapter)
put_device(dev);
return adapter;
}
EXPORT_SYMBOL_GPL(i2c_acpi_find_adapter_by_handle);
static struct i2c_client *i2c_acpi_find_client_by_adev(struct acpi_device *adev)
{
return i2c_find_device_by_fwnode(acpi_fwnode_handle(adev));
}
i2c: acpi: Unbind mux adapters before delete commit 3f858bbf04dbac934ac279aaee05d49eb9910051 upstream. There is an issue with ACPI overlay table removal specifically related to I2C multiplexers. Consider an ACPI SSDT Overlay that defines a PCA9548 I2C mux on an existing I2C bus. When this table is loaded we see the creation of a device for the overall PCA9548 chip and 8 further devices - one i2c_adapter each for the mux channels. These are all bound to their ACPI equivalents via an eventual invocation of acpi_bind_one(). When we unload the SSDT overlay we run into the problem. The ACPI devices are deleted as normal via acpi_device_del_work_fn() and the acpi_device_del_list. However, the following warning and stack trace is output as the deletion does not go smoothly: ------------[ cut here ]------------ kernfs: can not remove 'physical_node', no directory WARNING: CPU: 1 PID: 11 at fs/kernfs/dir.c:1674 kernfs_remove_by_name_ns+0xb9/0xc0 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u128:0 Not tainted 6.8.0-rc6+ #1 Hardware name: congatec AG conga-B7E3/conga-B7E3, BIOS 5.13 05/16/2023 Workqueue: kacpi_hotplug acpi_device_del_work_fn RIP: 0010:kernfs_remove_by_name_ns+0xb9/0xc0 Code: e4 00 48 89 ef e8 07 71 db ff 5b b8 fe ff ff ff 5d 41 5c 41 5d e9 a7 55 e4 00 0f 0b eb a6 48 c7 c7 f0 38 0d 9d e8 97 0a d5 ff <0f> 0b eb dc 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffff9f864008fb28 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8ef90a8d4940 RCX: 0000000000000000 RDX: ffff8f000e267d10 RSI: ffff8f000e25c780 RDI: ffff8f000e25c780 RBP: ffff8ef9186f9870 R08: 0000000000013ffb R09: 00000000ffffbfff R10: 00000000ffffbfff R11: ffff8f000e0a0000 R12: ffff9f864008fb50 R13: ffff8ef90c93dd60 R14: ffff8ef9010d0958 R15: ffff8ef9186f98c8 FS: 0000000000000000(0000) GS:ffff8f000e240000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f48f5253a08 CR3: 00000003cb82e000 CR4: 00000000003506f0 Call Trace: <TASK> ? kernfs_remove_by_name_ns+0xb9/0xc0 ? __warn+0x7c/0x130 ? kernfs_remove_by_name_ns+0xb9/0xc0 ? report_bug+0x171/0x1a0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? kernfs_remove_by_name_ns+0xb9/0xc0 ? kernfs_remove_by_name_ns+0xb9/0xc0 acpi_unbind_one+0x108/0x180 device_del+0x18b/0x490 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f device_unregister+0xd/0x30 i2c_del_adapter.part.0+0x1bf/0x250 i2c_mux_del_adapters+0xa1/0xe0 i2c_device_remove+0x1e/0x80 device_release_driver_internal+0x19a/0x200 bus_remove_device+0xbf/0x100 device_del+0x157/0x490 ? __pfx_device_match_fwnode+0x10/0x10 ? srso_return_thunk+0x5/0x5f device_unregister+0xd/0x30 i2c_acpi_notify+0x10f/0x140 notifier_call_chain+0x58/0xd0 blocking_notifier_call_chain+0x3a/0x60 acpi_device_del_work_fn+0x85/0x1d0 process_one_work+0x134/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> ---[ end trace 0000000000000000 ]--- ... repeated 7 more times, 1 for each channel of the mux ... The issue is that the binding of the ACPI devices to their peer I2C adapters is not correctly cleaned up. Digging deeper into the issue we see that the deletion order is such that the ACPI devices matching the mux channel i2c adapters are deleted first during the SSDT overlay removal. For each of the channels we see a call to i2c_acpi_notify() with ACPI_RECONFIG_DEVICE_REMOVE but, because these devices are not actually i2c_clients, nothing is done for them. Later on, after each of the mux channels has been dealt with, we come to delete the i2c_client representing the PCA9548 device. This is the call stack we see above, whereby the kernel cleans up the i2c_client including destruction of the mux and its channel adapters. At this point we do attempt to unbind from the ACPI peers but those peers no longer exist and so we hit the kernfs errors. The fix is to augment i2c_acpi_notify() to handle i2c_adapters. But, given that the life cycle of the adapters is linked to the i2c_client, instead of deleting the i2c_adapters during the i2c_acpi_notify(), we just trigger unbinding of the ACPI device from the adapter device, and allow the clean up of the adapter to continue in the way it always has. Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Fixes: 525e6fabeae2 ("i2c / ACPI: add support for ACPI reconfigure notifications") Cc: <stable@vger.kernel.org> # v4.8+ Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-13 06:16:32 +08:00
static struct i2c_adapter *i2c_acpi_find_adapter_by_adev(struct acpi_device *adev)
{
return i2c_find_adapter_by_fwnode(acpi_fwnode_handle(adev));
}
static int i2c_acpi_notify(struct notifier_block *nb, unsigned long value,
void *arg)
{
struct acpi_device *adev = arg;
struct i2c_board_info info;
acpi_handle adapter_handle;
struct i2c_adapter *adapter;
struct i2c_client *client;
switch (value) {
case ACPI_RECONFIG_DEVICE_ADD:
if (i2c_acpi_get_info(adev, &info, NULL, &adapter_handle))
break;
adapter = i2c_acpi_find_adapter_by_handle(adapter_handle);
if (!adapter)
break;
i2c_acpi_register_device(adapter, adev, &info);
put_device(&adapter->dev);
break;
case ACPI_RECONFIG_DEVICE_REMOVE:
if (!acpi_device_enumerated(adev))
break;
client = i2c_acpi_find_client_by_adev(adev);
i2c: acpi: Unbind mux adapters before delete commit 3f858bbf04dbac934ac279aaee05d49eb9910051 upstream. There is an issue with ACPI overlay table removal specifically related to I2C multiplexers. Consider an ACPI SSDT Overlay that defines a PCA9548 I2C mux on an existing I2C bus. When this table is loaded we see the creation of a device for the overall PCA9548 chip and 8 further devices - one i2c_adapter each for the mux channels. These are all bound to their ACPI equivalents via an eventual invocation of acpi_bind_one(). When we unload the SSDT overlay we run into the problem. The ACPI devices are deleted as normal via acpi_device_del_work_fn() and the acpi_device_del_list. However, the following warning and stack trace is output as the deletion does not go smoothly: ------------[ cut here ]------------ kernfs: can not remove 'physical_node', no directory WARNING: CPU: 1 PID: 11 at fs/kernfs/dir.c:1674 kernfs_remove_by_name_ns+0xb9/0xc0 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u128:0 Not tainted 6.8.0-rc6+ #1 Hardware name: congatec AG conga-B7E3/conga-B7E3, BIOS 5.13 05/16/2023 Workqueue: kacpi_hotplug acpi_device_del_work_fn RIP: 0010:kernfs_remove_by_name_ns+0xb9/0xc0 Code: e4 00 48 89 ef e8 07 71 db ff 5b b8 fe ff ff ff 5d 41 5c 41 5d e9 a7 55 e4 00 0f 0b eb a6 48 c7 c7 f0 38 0d 9d e8 97 0a d5 ff <0f> 0b eb dc 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffff9f864008fb28 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8ef90a8d4940 RCX: 0000000000000000 RDX: ffff8f000e267d10 RSI: ffff8f000e25c780 RDI: ffff8f000e25c780 RBP: ffff8ef9186f9870 R08: 0000000000013ffb R09: 00000000ffffbfff R10: 00000000ffffbfff R11: ffff8f000e0a0000 R12: ffff9f864008fb50 R13: ffff8ef90c93dd60 R14: ffff8ef9010d0958 R15: ffff8ef9186f98c8 FS: 0000000000000000(0000) GS:ffff8f000e240000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f48f5253a08 CR3: 00000003cb82e000 CR4: 00000000003506f0 Call Trace: <TASK> ? kernfs_remove_by_name_ns+0xb9/0xc0 ? __warn+0x7c/0x130 ? kernfs_remove_by_name_ns+0xb9/0xc0 ? report_bug+0x171/0x1a0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? kernfs_remove_by_name_ns+0xb9/0xc0 ? kernfs_remove_by_name_ns+0xb9/0xc0 acpi_unbind_one+0x108/0x180 device_del+0x18b/0x490 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f device_unregister+0xd/0x30 i2c_del_adapter.part.0+0x1bf/0x250 i2c_mux_del_adapters+0xa1/0xe0 i2c_device_remove+0x1e/0x80 device_release_driver_internal+0x19a/0x200 bus_remove_device+0xbf/0x100 device_del+0x157/0x490 ? __pfx_device_match_fwnode+0x10/0x10 ? srso_return_thunk+0x5/0x5f device_unregister+0xd/0x30 i2c_acpi_notify+0x10f/0x140 notifier_call_chain+0x58/0xd0 blocking_notifier_call_chain+0x3a/0x60 acpi_device_del_work_fn+0x85/0x1d0 process_one_work+0x134/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> ---[ end trace 0000000000000000 ]--- ... repeated 7 more times, 1 for each channel of the mux ... The issue is that the binding of the ACPI devices to their peer I2C adapters is not correctly cleaned up. Digging deeper into the issue we see that the deletion order is such that the ACPI devices matching the mux channel i2c adapters are deleted first during the SSDT overlay removal. For each of the channels we see a call to i2c_acpi_notify() with ACPI_RECONFIG_DEVICE_REMOVE but, because these devices are not actually i2c_clients, nothing is done for them. Later on, after each of the mux channels has been dealt with, we come to delete the i2c_client representing the PCA9548 device. This is the call stack we see above, whereby the kernel cleans up the i2c_client including destruction of the mux and its channel adapters. At this point we do attempt to unbind from the ACPI peers but those peers no longer exist and so we hit the kernfs errors. The fix is to augment i2c_acpi_notify() to handle i2c_adapters. But, given that the life cycle of the adapters is linked to the i2c_client, instead of deleting the i2c_adapters during the i2c_acpi_notify(), we just trigger unbinding of the ACPI device from the adapter device, and allow the clean up of the adapter to continue in the way it always has. Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Fixes: 525e6fabeae2 ("i2c / ACPI: add support for ACPI reconfigure notifications") Cc: <stable@vger.kernel.org> # v4.8+ Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-03-13 06:16:32 +08:00
if (client) {
i2c_unregister_device(client);
put_device(&client->dev);
}
adapter = i2c_acpi_find_adapter_by_adev(adev);
if (adapter) {
acpi_unbind_one(&adapter->dev);
put_device(&adapter->dev);
}
break;
}
return NOTIFY_OK;
}
struct notifier_block i2c_acpi_notifier = {
.notifier_call = i2c_acpi_notify,
};
/**
* i2c_acpi_new_device_by_fwnode - Create i2c-client for the Nth I2cSerialBus resource
* @fwnode: fwnode with the ACPI resources to get the client from
* @index: Index of ACPI resource to get
* @info: describes the I2C device; note this is modified (addr gets set)
* Context: can sleep
*
* By default the i2c subsys creates an i2c-client for the first I2cSerialBus
* resource of an acpi_device, but some acpi_devices have multiple I2cSerialBus
* resources, in that case this function can be used to create an i2c-client
* for other I2cSerialBus resources in the Current Resource Settings table.
*
* Also see i2c_new_client_device, which this function calls to create the
* i2c-client.
*
* Returns a pointer to the new i2c-client, or error pointer in case of failure.
* Specifically, -EPROBE_DEFER is returned if the adapter is not found.
*/
struct i2c_client *i2c_acpi_new_device_by_fwnode(struct fwnode_handle *fwnode,
int index,
struct i2c_board_info *info)
{
struct i2c_acpi_lookup lookup;
struct i2c_adapter *adapter;
struct acpi_device *adev;
LIST_HEAD(resource_list);
int ret;
adev = to_acpi_device_node(fwnode);
if (!adev)
return ERR_PTR(-ENODEV);
memset(&lookup, 0, sizeof(lookup));
lookup.info = info;
lookup.device_handle = acpi_device_handle(adev);
lookup.index = index;
ret = acpi_dev_get_resources(adev, &resource_list,
i2c_acpi_fill_info, &lookup);
if (ret < 0)
return ERR_PTR(ret);
acpi_dev_free_resource_list(&resource_list);
if (!info->addr)
return ERR_PTR(-EADDRNOTAVAIL);
adapter = i2c_acpi_find_adapter_by_handle(lookup.adapter_handle);
if (!adapter)
return ERR_PTR(-EPROBE_DEFER);
return i2c_new_client_device(adapter, info);
}
EXPORT_SYMBOL_GPL(i2c_acpi_new_device_by_fwnode);
bool i2c_acpi_waive_d0_probe(struct device *dev)
{
struct i2c_driver *driver = to_i2c_driver(dev->driver);
struct acpi_device *adev = ACPI_COMPANION(dev);
return driver->flags & I2C_DRV_ACPI_WAIVE_D0_PROBE &&
adev && adev->power.state_for_enumeration >= adev->power.state;
}
EXPORT_SYMBOL_GPL(i2c_acpi_waive_d0_probe);
#ifdef CONFIG_ACPI_I2C_OPREGION
static int acpi_gsb_i2c_read_bytes(struct i2c_client *client,
u8 cmd, u8 *data, u8 data_len)
{
struct i2c_msg msgs[2];
int ret;
u8 *buffer;
buffer = kzalloc(data_len, GFP_KERNEL);
if (!buffer)
return AE_NO_MEMORY;
msgs[0].addr = client->addr;
msgs[0].flags = client->flags;
msgs[0].len = 1;
msgs[0].buf = &cmd;
msgs[1].addr = client->addr;
msgs[1].flags = client->flags | I2C_M_RD;
msgs[1].len = data_len;
msgs[1].buf = buffer;
ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
i2c: core: ACPI: Log device not acking errors at dbg loglevel 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 <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-04-23 01:58:00 +08:00
if (ret < 0) {
/* Getting a NACK is unfortunately normal with some DSTDs */
if (ret == -EREMOTEIO)
dev_dbg(&client->adapter->dev, "i2c read %d bytes from client@%#x starting at reg %#x failed, error: %d\n",
data_len, client->addr, cmd, ret);
else
dev_err(&client->adapter->dev, "i2c read %d bytes from client@%#x starting at reg %#x failed, error: %d\n",
data_len, client->addr, cmd, ret);
/* 2 transfers must have completed successfully */
} else if (ret == 2) {
memcpy(data, buffer, data_len);
ret = 0;
} else {
ret = -EIO;
i2c: core: ACPI: Log device not acking errors at dbg loglevel 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 <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-04-23 01:58:00 +08:00
}
kfree(buffer);
return ret;
}
static int acpi_gsb_i2c_write_bytes(struct i2c_client *client,
u8 cmd, u8 *data, u8 data_len)
{
struct i2c_msg msgs[1];
u8 *buffer;
int ret = AE_OK;
buffer = kzalloc(data_len + 1, GFP_KERNEL);
if (!buffer)
return AE_NO_MEMORY;
buffer[0] = cmd;
memcpy(buffer + 1, data, data_len);
msgs[0].addr = client->addr;
msgs[0].flags = client->flags;
msgs[0].len = data_len + 1;
msgs[0].buf = buffer;
ret = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs));
kfree(buffer);
if (ret < 0) {
dev_err(&client->adapter->dev, "i2c write failed: %d\n", ret);
return ret;
}
/* 1 transfer must have completed successfully */
return (ret == 1) ? 0 : -EIO;
}
static acpi_status
i2c_acpi_space_handler(u32 function, acpi_physical_address command,
u32 bits, u64 *value64,
void *handler_context, void *region_context)
{
struct gsb_buffer *gsb = (struct gsb_buffer *)value64;
struct i2c_acpi_handler_data *data = handler_context;
struct acpi_connection_info *info = &data->info;
struct acpi_resource_i2c_serialbus *sb;
struct i2c_adapter *adapter = data->adapter;
struct i2c_client *client;
struct acpi_resource *ares;
u32 accessor_type = function >> 16;
u8 action = function & ACPI_IO_MASK;
acpi_status ret;
int status;
ret = acpi_buffer_to_resource(info->connection, info->length, &ares);
if (ACPI_FAILURE(ret))
return ret;
client = kzalloc(sizeof(*client), GFP_KERNEL);
if (!client) {
ret = AE_NO_MEMORY;
goto err;
}
if (!value64 || !i2c_acpi_get_i2c_resource(ares, &sb)) {
ret = AE_BAD_PARAMETER;
goto err;
}
client->adapter = adapter;
client->addr = sb->slave_address;
if (sb->access_mode == ACPI_I2C_10BIT_MODE)
client->flags |= I2C_CLIENT_TEN;
switch (accessor_type) {
case ACPI_GSB_ACCESS_ATTRIB_SEND_RCV:
if (action == ACPI_READ) {
status = i2c_smbus_read_byte(client);
if (status >= 0) {
gsb->bdata = status;
status = 0;
}
} else {
status = i2c_smbus_write_byte(client, gsb->bdata);
}
break;
case ACPI_GSB_ACCESS_ATTRIB_BYTE:
if (action == ACPI_READ) {
status = i2c_smbus_read_byte_data(client, command);
if (status >= 0) {
gsb->bdata = status;
status = 0;
}
} else {
status = i2c_smbus_write_byte_data(client, command,
gsb->bdata);
}
break;
case ACPI_GSB_ACCESS_ATTRIB_WORD:
if (action == ACPI_READ) {
status = i2c_smbus_read_word_data(client, command);
if (status >= 0) {
gsb->wdata = status;
status = 0;
}
} else {
status = i2c_smbus_write_word_data(client, command,
gsb->wdata);
}
break;
case ACPI_GSB_ACCESS_ATTRIB_BLOCK:
if (action == ACPI_READ) {
status = i2c_smbus_read_block_data(client, command,
gsb->data);
if (status >= 0) {
gsb->len = status;
status = 0;
}
} else {
status = i2c_smbus_write_block_data(client, command,
gsb->len, gsb->data);
}
break;
case ACPI_GSB_ACCESS_ATTRIB_MULTIBYTE:
if (action == ACPI_READ) {
status = acpi_gsb_i2c_read_bytes(client, command,
gsb->data, info->access_length);
} else {
status = acpi_gsb_i2c_write_bytes(client, command,
gsb->data, info->access_length);
}
break;
default:
dev_warn(&adapter->dev, "protocol 0x%02x not supported for client 0x%02x\n",
accessor_type, client->addr);
ret = AE_BAD_PARAMETER;
goto err;
}
gsb->status = status;
err:
kfree(client);
ACPI_FREE(ares);
return ret;
}
int i2c_acpi_install_space_handler(struct i2c_adapter *adapter)
{
acpi_handle handle;
struct i2c_acpi_handler_data *data;
acpi_status status;
if (!adapter->dev.parent)
return -ENODEV;
handle = ACPI_HANDLE(adapter->dev.parent);
if (!handle)
return -ENODEV;
data = kzalloc(sizeof(struct i2c_acpi_handler_data),
GFP_KERNEL);
if (!data)
return -ENOMEM;
data->adapter = adapter;
status = acpi_bus_attach_private_data(handle, (void *)data);
if (ACPI_FAILURE(status)) {
kfree(data);
return -ENOMEM;
}
status = acpi_install_address_space_handler(handle,
ACPI_ADR_SPACE_GSBUS,
&i2c_acpi_space_handler,
NULL,
data);
if (ACPI_FAILURE(status)) {
dev_err(&adapter->dev, "Error installing i2c space handler\n");
acpi_bus_detach_private_data(handle);
kfree(data);
return -ENOMEM;
}
return 0;
}
void i2c_acpi_remove_space_handler(struct i2c_adapter *adapter)
{
acpi_handle handle;
struct i2c_acpi_handler_data *data;
acpi_status status;
if (!adapter->dev.parent)
return;
handle = ACPI_HANDLE(adapter->dev.parent);
if (!handle)
return;
acpi_remove_address_space_handler(handle,
ACPI_ADR_SPACE_GSBUS,
&i2c_acpi_space_handler);
status = acpi_bus_get_private_data(handle, (void **)&data);
if (ACPI_SUCCESS(status))
kfree(data);
acpi_bus_detach_private_data(handle);
}
#endif /* CONFIG_ACPI_I2C_OPREGION */