From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-43171.protonmail.ch (mail-43171.protonmail.ch [185.70.43.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5485A439009; Wed, 15 Jul 2026 11:35:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.43.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784115353; cv=none; b=ayuCeH6snwqBlw+2vdnjpPOLsMaeu2kSiwknFuTQC7E4ZcSqfbfRxvW+jyBlgQ1fDPPKo/7ZA6UwIjQmqNBoC2vVd0hkDqvgDM/BbXKBAXIIgfnsFx3+Qp5MMw8QywYuJLCuX5axp63non9PXHMaRUvn9AXLTdFXpbPJrirLlE4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784115353; c=relaxed/simple; bh=yT4MVaeHQyVB9n7HPL6AfqF1C+RpXIhVO9zZ6Cm40H8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=CAbKtWTxhgbLFZsJFJthaMuXV0YGeg4vDi4ZM8k16x6vSqdZB6pMY9YvnzCONo1GcILyfhP0WCPxcpwz3e/jM9dUdPRxLYPFVrYkamavecHtUnU5xAui2AUopTd6XgsNvzDXufX7L4IeIyDjTmkNJCOpuGN23tqjJt2NDaC5gcc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=geanix.com; spf=pass smtp.mailfrom=geanix.com; dkim=pass (2048-bit key) header.d=geanix.com header.i=@geanix.com header.b=WivdqmVR; arc=none smtp.client-ip=185.70.43.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=geanix.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=geanix.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=geanix.com header.i=@geanix.com header.b="WivdqmVR" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=geanix.com; s=protonmail3; t=1784115345; x=1784374545; bh=vw3eiTKMHGN7k4PMh36M/r9ybREuXYjf2b40KXBhK/Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:From:To: Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=WivdqmVRvHFbAn38DXpzLC7sX7CWeBTekytpnuzBvc00Q+iguxkcgzbnlWgef+vu+ bglbMc7zXb0CplLO1OHgPO+WCD8G56S/pQYnT6kxIIfetJ6lvxXp0lMIdZdmX9wg91 QgbVkacaMfxnjTa2HO5U7eL1TVAXU1uuMn9sPArmOn8W8eNoi5PECZydtaQuYDvBgG yqN7JcUMtLpeCx6Zjla7CLOM59JKB9Qvxn67LmNdQbp59X4iDz/MGTjZy6IB2eA4v6 IxWDiwfXX2Kl8WhHSjugZFwkuEJmYvW+viWkEBWyNZE+nxnmzklp7vJeRBU4C/Ejso npXDT1LBpg3QQ== X-Pm-Submission-Id: 4h0YyQ5SdGz1DDL5 From: Esben Haabendal To: "Andy Shevchenko" Cc: "Jonathan Cameron" , "Lars-Peter Clausen" , "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , "Martin Kepplinger" , "Sean Nyekjaer" , "David Lechner" , Nuno =?utf-8?Q?S=C3=A1?= , "Andy Shevchenko" , "Martin Kepplinger" , , , Subject: Re: [PATCH 2/2] iio: accel: mma8452: Allow open drain interrupt pin configuration In-Reply-To: (Andy Shevchenko's message of "Wed, 15 Jul 2026 11:42:06 +0300") References: <20260715-mma8452-open-drain-v1-0-b1dd2a440c60@geanix.com> <20260715-mma8452-open-drain-v1-2-b1dd2a440c60@geanix.com> Date: Wed, 15 Jul 2026 13:35:41 +0200 Message-ID: <87ldbco582.fsf@geanix.com> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain "Andy Shevchenko" writes: > On Wed, Jul 15, 2026 at 10:07:39AM +0200, Esben Haabendal wrote: >> When sharing interrupt line with other chips, the interrupt pin most >> likely needs to be configured in open-drain mode instead of push-pull. >> If this is needed, you must add drive-open-drain property to the >> device-tree. > > ... > >> if (client->irq) { >> ret = request_threaded_irq(client->irq, NULL, mma8452_interrupt, >> - IRQF_TRIGGER_LOW | IRQF_ONESHOT, >> + IRQF_TRIGGER_LOW | IRQF_ONESHOT | >> + data->open_drain ? IRQF_SHARED : 0, >> client->name, indio_dev); > > Why do we care? Care about what exactly? We need to add IRQF_SHARED flag in order to allow shared interrupt, and we should not add it when using (the default) push-pull mode. > The (hidden) problem this will have in the future is that the IRQ core > will splat a warning in case that other shared IRQs might be > configured with different flags. Putting that flag conditionally makes > it a mine field for the users. Instead just unconditionally add that > flag and we will get reports as soon as there will be a user that > shares the same interrupt pin with some other devices which drivers do > not use the same settings. If we add the IRQF_SHARED flag unconditionally, it will be set also when push-pull mode is enabled. I don't see how the kernel will be able to notice that that is not going to work. If you have another device that uses IRQF_TRIGGER_LOW|IRF_ONESHOT|IRQF_SHARED, it will not work with the MMA8452 device when configured as push-pull. > Also setting to _LOW in the flags unconditionally is a (historic) bug. > The problem is that we might not fix it without breaking the existing > users which omit that flag in DT. Ok. So let's leave that as is for now. /Esben