From: Hans de Goede <hdegoede@redhat.com>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Mark Gross <mgross@linux.intel.com>,
platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org, Moody Salem <moody@uniswap.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] ACPI / scan: Don't create platform device for INT3515 ACPI nodes
Date: Mon, 4 Jan 2021 12:59:39 +0100 [thread overview]
Message-ID: <ae94a191-4273-0000-deda-4859034343b8@redhat.com> (raw)
In-Reply-To: <20201223143644.33341-1-heikki.krogerus@linux.intel.com>
Hi,
On 12/23/20 3:36 PM, Heikki Krogerus wrote:
> There are several reports about the tps6598x causing
> interrupt flood on boards with the INT3515 ACPI node, which
> then causes instability. There appears to be several
> problems with the interrupt. One problem is that the
> I2CSerialBus resources do not always map to the Interrupt
> resource with the same index, but that is not the only
> problem. We have not been able to come up with a solution
> for all the issues, and because of that disabling the device
> for now.
>
> The PD controller on these platforms is autonomous, and the
> purpose for the driver is primarily to supply status to the
> userspace, so this will not affect any functionality.
>
> Reported-by: Moody Salem <moody@uniswap.org>
> Fixes: a3dd034a1707 ("ACPI / scan: Create platform device for INT3515 ACPI nodes")
> Cc: stable@vger.kernel.org
> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1883511
> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Thank you for your patch, I've applied this patch to my review-hans
branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans
Note it will show up in my review-hans branch once I've pushed my
local branch there, which might take a while.
Once I've run some tests on this branch the patches there will be
added to the platform-drivers-x86/for-next branch and eventually
will be included in the pdx86 pull-request to Linus for the next
merge-window.
Regards,
Hans
> ---
> drivers/platform/x86/i2c-multi-instantiate.c | 31 +++++++++++++++-----
> 1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/platform/x86/i2c-multi-instantiate.c b/drivers/platform/x86/i2c-multi-instantiate.c
> index 6acc8457866e1..e1df665d3ad31 100644
> --- a/drivers/platform/x86/i2c-multi-instantiate.c
> +++ b/drivers/platform/x86/i2c-multi-instantiate.c
> @@ -166,13 +166,29 @@ static const struct i2c_inst_data bsg2150_data[] = {
> {}
> };
>
> -static const struct i2c_inst_data int3515_data[] = {
> - { "tps6598x", IRQ_RESOURCE_APIC, 0 },
> - { "tps6598x", IRQ_RESOURCE_APIC, 1 },
> - { "tps6598x", IRQ_RESOURCE_APIC, 2 },
> - { "tps6598x", IRQ_RESOURCE_APIC, 3 },
> - {}
> -};
> +/*
> + * Device with _HID INT3515 (TI PD controllers) has some unresolved interrupt
> + * issues. The most common problem seen is interrupt flood.
> + *
> + * There are at least two known causes. Firstly, on some boards, the
> + * I2CSerialBus resource index does not match the Interrupt resource, i.e. they
> + * are not one-to-one mapped like in the array below. Secondly, on some boards
> + * the irq line from the PD controller is not actually connected at all. But the
> + * interrupt flood is also seen on some boards where those are not a problem, so
> + * there are some other problems as well.
> + *
> + * Because of the issues with the interrupt, the device is disabled for now. If
> + * you wish to debug the issues, uncomment the below, and add an entry for the
> + * INT3515 device to the i2c_multi_instance__ids table.
> + *
> + * static const struct i2c_inst_data int3515_data[] = {
> + * { "tps6598x", IRQ_RESOURCE_APIC, 0 },
> + * { "tps6598x", IRQ_RESOURCE_APIC, 1 },
> + * { "tps6598x", IRQ_RESOURCE_APIC, 2 },
> + * { "tps6598x", IRQ_RESOURCE_APIC, 3 },
> + * { }
> + * };
> + */
>
> /*
> * Note new device-ids must also be added to i2c_multi_instantiate_ids in
> @@ -181,7 +197,6 @@ static const struct i2c_inst_data int3515_data[] = {
> static const struct acpi_device_id i2c_multi_inst_acpi_ids[] = {
> { "BSG1160", (unsigned long)bsg1160_data },
> { "BSG2150", (unsigned long)bsg2150_data },
> - { "INT3515", (unsigned long)int3515_data },
> { }
> };
> MODULE_DEVICE_TABLE(acpi, i2c_multi_inst_acpi_ids);
>
next prev parent reply other threads:[~2021-01-04 12:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-23 14:36 Heikki Krogerus
2020-12-23 16:34 ` Andy Shevchenko
2021-01-04 11:59 ` Hans de Goede [this message]
2021-01-04 12:23 ` Andy Shevchenko
2021-01-04 13:59 ` Hans de Goede
2021-01-04 14:09 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ae94a191-4273-0000-deda-4859034343b8@redhat.com \
--to=hdegoede@redhat.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgross@linux.intel.com \
--cc=moody@uniswap.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®