From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from codeconstruct.com.au (pi.codeconstruct.com.au [203.29.241.158]) (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 E5B461607BD; Wed, 26 Jun 2024 08:18:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=203.29.241.158 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719389920; cv=none; b=WjB+vz3Tk54IB/lO7wk7u4g2VdORaezooDm//UwxdApfZsaqtAj8iIgtUzQbcLyijnxQN/l5cIwkusCxNUlHH+B0hBHdp54YG2ls1mCjvdyoD3wCdMsHb+N5zhZ1+qMwxfjRiqlVrgjJOA33bd7U4YqvHpL5xyraU8MRzkRXwxw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719389920; c=relaxed/simple; bh=tLqxjdvKncjvyf03Lhs0i9bSG7lfZSHlzhwH58h2wN0=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=Ihb4A9Th0qdGjafePAHgy56VlBMiC/JmrI50Y2Flk8VP/R2+97DGDR3jKYdQO8VpTkwABP/pdYca21AOkcmxYajF2yLVtN5V+ZZJWfzu1oXa6wsR0Zd3Hf706g/4Fme8BRU3PJG2VqECKvFHIWUcPbUHourOjVU6sdVM2M7zDPs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codeconstruct.com.au; spf=pass smtp.mailfrom=codeconstruct.com.au; dkim=pass (2048-bit key) header.d=codeconstruct.com.au header.i=@codeconstruct.com.au header.b=N3WVX5Pm; arc=none smtp.client-ip=203.29.241.158 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codeconstruct.com.au Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=codeconstruct.com.au Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=codeconstruct.com.au header.i=@codeconstruct.com.au header.b="N3WVX5Pm" Received: from pecola.lan (unknown [159.196.93.152]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id 423DC200EE; Wed, 26 Jun 2024 16:18:31 +0800 (AWST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeconstruct.com.au; s=2022a; t=1719389913; bh=tLqxjdvKncjvyf03Lhs0i9bSG7lfZSHlzhwH58h2wN0=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=N3WVX5PmAnQAqeowtVcZ488EtThGN08BtJWVXcoy22JwMyw501suKxzDx8T7zKjM2 tdVm4H7Pn1oMa3vej7VwUHZPgHzwfS9Lk9oWPVMo8IlmlR2FTpTHH6D5zEM2Sv00dj CPGGtYnzPHAHQpkBQ15TjkVeopHfXc6ozGXDY4xqdmxDhQPRH08C9tDsosQ9ASuBei wsWQlDxHPsZo9T23leb7BrD3BSUb4HQ8K3wdJwJbfIpEg0wLCDBDY4koSuJFhIDI7y TqzW0Ekk7zslyVwI7j3EhZ2n8ItW+kkEz0lyxR9peXgGTZDEagg9R+05/nm13gjsKq 4/9zy4Y+pwlfQ== Message-ID: Subject: Re: [PATCH 1/2] dt-bindings: i3c: dw: Add property to select IBI ops From: Jeremy Kerr To: Krzysztof Kozlowski , Aniket , Alexandre Belloni , Joel Stanley , Billy Tsai , Rob Herring , Krzysztof Kozlowski Cc: linux-i3c@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Date: Wed, 26 Jun 2024 16:18:31 +0800 In-Reply-To: References: <20240626052238.1577580-1-aniketmaurya@google.com> <20240626052238.1577580-2-aniketmaurya@google.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Hi Krysztof, > > > +=C2=A0 ibi-capable: > > > +=C2=A0=C2=A0=C2=A0 description: Set to select IBI ops. >=20 > What are IBI ops? Standard form letter: >=20 > You described the desired Linux feature or behavior, not the actual > hardware. In this case it is the actual hardware; my understanding is that the gateware IP can be configured to support in-band-interrupts or not, before being baked-in to hardware. > > Wouldn't the compatible string select whether the hardware instance > > supports IBI or not? > >=20 > > I'd imagine that each specific synthesis of the DW IP would imply > > corresponding hardware settings, and so would warrant its own > > compatible > > value. > >=20 > > Maybe one for the DT folks: would this work better as individual > > properties? Is there a policy here? >=20 > Usually if feature is specific to given hardware, e.g. always capable > of foobar, then it can be deduced from compatible, so no need for new > property. Sounds good. Aniket: the hardware you're dealing with there may need a new, specific compatible property, which will dictate whether we enable IBIs in the driver. For cases where no other special behaviour is required, we can represent this just as an entry in the OF match table. Cheers, Jeremy