Linux I2C development
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
Cc: Svyatoslav Ryhel <clamor95@gmail.com>,
	Andi Shyti <andi.shyti@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>, Wolfram Sang <wsa@kernel.org>,
	linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/2] i2c: Add GPIO-based hotplug gate
Date: Mon, 31 Jul 2023 14:59:41 +0200	[thread overview]
Message-ID: <fdc513a3-c0e0-c57d-5c9a-8da6fa2f54e2@linaro.org> (raw)
In-Reply-To: <ZMd1qI7RjQhpI8zO@qmqm.qmqm.pl>

On 31/07/2023 10:49, Michał Mirosław wrote:
> On Mon, Jul 31, 2023 at 08:58:14AM +0200, Krzysztof Kozlowski wrote:
>> On 30/07/2023 23:55, Michał Mirosław wrote:
>>> On Sun, Jul 30, 2023 at 10:30:56PM +0200, Krzysztof Kozlowski wrote:
>>>> On 29/07/2023 18:08, Svyatoslav Ryhel wrote:
>>>>> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>>>>>
>>>>> Implement driver for hot-plugged I2C busses, where some devices on
>>>>> a bus are hot-pluggable and their presence is indicated by GPIO line.
>>> [...] 
>>>>> +	priv->irq = platform_get_irq(pdev, 0);
>>>>> +	if (priv->irq < 0)
>>>>> +		return dev_err_probe(&pdev->dev, priv->irq,
>>>>> +				     "failed to get IRQ %d\n", priv->irq);
>>>>> +
>>>>> +	ret = devm_request_threaded_irq(&pdev->dev, priv->irq, NULL,
>>>>> +					i2c_hotplug_interrupt,
>>>>> +					IRQF_ONESHOT | IRQF_SHARED,
>>>>
>>>> Shared IRQ with devm is a recipe for disaster. Are you sure this is a
>>>> shared one? You have a remove() function which also points that it is
>>>> not safe. You can:
>>>> 1. investigate to be sure it is 100% safe (please document why do you
>>>> think it is safe)
>>>
>>> Could you elaborate on what is unsafe in using devm with shared
>>> interrupts (as compared to non-shared or not devm-managed)?
>>>
>>> The remove function is indeed reversing the order of cleanup. The
>>> shutdown path can be fixed by removing `remove()` and adding
>>> `devm_add_action_or_reset(...deactivate)` before the IRQ is registered.
>> Shared interrupt might be triggered easily by other device between
>> remove() and irq release function (devm_free_irq() or whatever it is
>> called).
> 
> This is no different tham a non-shared interrupt that can be triggered
> by the device being removed. Since devres will release the IRQ first,
> before freeing the driver data, the interrupt hander will see consistent
> driver-internal state. (The difference between remove() and devres
> release phase is that for the latter sysfs files are already removed.)

True, therefore non-devm interrupts are recommended also in such case.
Maybe one of my solutions is actually not recommended.

However if done right, driver with non-shared interrupts, is expected to
disable interrupts in remove(), thus there is no risk. We have big
discussions in the past about it, so feel free to dig through LKML to
read more about. Anyway shared and devm is a clear no go.

Best regards,
Krzysztof


  reply	other threads:[~2023-07-31 12:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-29 16:08 [PATCH v3 0/2] GPIO-based hotplug i2c bus Svyatoslav Ryhel
2023-07-29 16:08 ` [PATCH v3 1/2] dt-bindings: i2c: add binding for i2c-hotplug-gpio Svyatoslav Ryhel
2023-08-05 19:23   ` Krzysztof Kozlowski
2023-08-11 17:37   ` Rob Herring
2023-08-12 21:46     ` Michał Mirosław
2023-08-15 20:00       ` Wolfram Sang
2023-07-29 16:08 ` [PATCH v3 2/2] i2c: Add GPIO-based hotplug gate Svyatoslav Ryhel
2023-07-30 20:25   ` Andi Shyti
2023-07-30 22:11     ` Michał Mirosław
2023-07-31 23:01       ` Michał Mirosław
2023-08-04 23:45         ` Andi Shyti
2023-08-10 22:55           ` Michał Mirosław
2023-07-30 20:30   ` Krzysztof Kozlowski
2023-07-30 21:55     ` Michał Mirosław
2023-07-31  6:58       ` Krzysztof Kozlowski
2023-07-31  8:49         ` Michał Mirosław
2023-07-31 12:59           ` Krzysztof Kozlowski [this message]
2023-07-31 22:50             ` Michał Mirosław
2023-08-05 19:17               ` Krzysztof Kozlowski
2023-08-10 21:52                 ` Michał Mirosław
2023-08-15  5:20                   ` Krzysztof Kozlowski
2023-07-30 17:49 ` [PATCH v3 0/2] GPIO-based hotplug i2c bus Andi Shyti
2023-07-30 18:21   ` Svyatoslav Ryhel

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=fdc513a3-c0e0-c57d-5c9a-8da6fa2f54e2@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=andi.shyti@kernel.org \
    --cc=clamor95@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=robh+dt@kernel.org \
    --cc=wsa@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