From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 C32AF2E0920 for ; Thu, 8 Jan 2026 21:33:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767907982; cv=none; b=mx5KERvv1kHWxY8ICU8QdJXS2/dPi8Hcbymg2Wt/0FNCLo8IdNObj92BuEwYav2m8QcJgee5VpXADuQSuOOC7DOpzplOiJloiFxqoicBEgC6sv23STo82bzSsuhrScNHrmM6UiaNK2Jgmu1oeek8st9l9ZRsPkh0SQCPsaR08Js= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767907982; c=relaxed/simple; bh=fsnzTE7aboqvndYQZgPDM8OtLedz0mO/G3g5gqRJlSM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=DpTwjdVtTjt82he+eed69BCJzQwsYUiRrDTZJtnoZFg5DGWLa4yNd+Mi61SieJ12sid1urXZlEO6Mbcwt64hYw7eLawbVGf6Bwtgxl2HRfrNiy1XqtYMu6JDLk33Dn0RYKMWoUDyyR6Zt3q98RNXeKdOfheEd4pIzd3nK2UJp9E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=bsIqDv7Z; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=XdofNkYl; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="bsIqDv7Z"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="XdofNkYl" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1767907978; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JFsuP3jUuInvtfPKzSnOum7Xzbk9vaPL8BxXSyvwj9o=; b=bsIqDv7Z0a5KXVZw1tcEeacFF4lVV80AxCfofOtqj8pVSZZ6U71Gb+aIGh6Rzr0U2mAbDD SYpWpIBb5MgdgfoVYBKA5B9Rd4I2B/RbvBl71RJqn/FdeV5uC1Os0V9/bbeiUEilDInsPE WE3GbE3sQXXVs7NpkSEKZugjhbBg7vY0NU/T+603QCqnygOEeld9g5pjUA1pi7U1wP6GeX wv1+JUtJIcDejF96+ePbZ31jifVBcRG6ulpJ3sQ7SKGE54v0q2E1YJUc9pNenfwM8xcqkG ncevg0oCbdixFBnZOAZ8UF8Six+J58NUDWCaOIRAAUcmbyFp99JNnyYXn2WZ4g== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1767907978; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JFsuP3jUuInvtfPKzSnOum7Xzbk9vaPL8BxXSyvwj9o=; b=XdofNkYlWUVuYqlYd/USBwe+kzkJe89OD2fwyhWDAP3sVZdB2QnOYdEiHVZ2xQP+wrtWYp BBkiNwz+7XHbDTAw== To: Marc Zyngier , Luigi Rizzo Cc: bhelgaas@google.com, linux-kernel@vger.kernel.org Subject: Re: [patch 1/2] irqchip/msi-lib: Honor the MSI_FLAG_PCI_MSI_MASK_PARENT flag In-Reply-To: <86ms3amqzm.wl-maz@kernel.org> References: <20250903135433.380783272@linutronix.de> <20251220193120.3339162-1-lrizzo@google.com> <87tsxkdp6s.wl-maz@kernel.org> <86ms3amqzm.wl-maz@kernel.org> Date: Thu, 08 Jan 2026 22:32:58 +0100 Message-ID: <871pjzu6wl.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Mon, Dec 22 2025 at 16:16, Marc Zyngier wrote: >> > > Once we remove the costly readback, is there any remaining reason >> > > to overwrite [un]mask_irq() with irq_chip_[un]mask_parent() ? >> > >> > So you are effectively not masking at all and just rely on hope >> > instead. I have the utmost confidence in this sort of stuff. Totally. >> >> I don't understand the above comment. >> Masking happens as a result of the PCIe write, >> which will eventually reach the device. The presence of the >> readback does nothing to accelerate the landing of the write. > > It doesn't accelerate it. It *guarantees* that the write is observed > and has taken effect. It acts as a completion barrier. Without it, the > write can be buffered at an arbitrary location in the interconnect, or > stored in the device but not acted upon. > > What you have here is the equivalent of throwing a message in a bottle > at sea, and expecting a guaranteed reply. https://xkcd.com/3150/