From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (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 C7B0F3976A4 for ; Fri, 3 Apr 2026 16:24:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775233489; cv=none; b=C/23edzphLB6xgw5Esxl474za8i3sVXy4ERpLiSvqtF28pK8iAvokaHm/HsgEfnvjaDMJ613DWK6WBkcMIEIwCT/MHSOvwnhUo5It6wPhoSLa1Fc/C1OMYVhpPG7k/JnGWigPTZSW+gHlChzf6g1PBWVsQAKin9sN/UT6J7WeI8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775233489; c=relaxed/simple; bh=B/1R7RqKW1Cz01kFITHEnh+h+u+nAZKs/FIuyXBafg4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ObBn7gNV2jv0QmTNXFaVbePKHfFQoimpGQpx78ij+UA4UVN0S3/PLHYa7BGN4WIqWizzbz3kSgaqXFH92egCoKz4WqsPrboKbrox1u5F7u3WqNy/hyRRLYSalUU1hevCFe8v52JXchWiq9S7iYbMMTzpvgUcIUqqWn0T/vR0ZxE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=jxUjCiEk; arc=none smtp.client-ip=185.246.85.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="jxUjCiEk" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 2D4004E428C8 for ; Fri, 3 Apr 2026 16:24:46 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id D7A90603C1; Fri, 3 Apr 2026 16:24:45 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id CFDB5104500FB; Fri, 3 Apr 2026 18:24:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1775233485; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=53h5lBCesrRbN58GkWw0dPf7qTDPSdaW29s2knM9AY8=; b=jxUjCiEkIBuUy7VstcorIWgzSFDtFWxoH6PKRen+aJKF8kONNxoKnOuXbIzj0vEPrp+H1N d0CFHUknyrRZTl2DSNDyi2IEJD5uZP3fWARsFzwzZnCNQw0mhwhI2xZO9qumfDujTKxKX8 4HbraXWSO7D2GpZgBnXMUR1o3oFtdwGFVuBqXVvUl7lVbsT6rJasQhwi/Q0cBeIb25bnDp h6/YB3wp0gd/pvm3bR7+tjoWxneWJNAK7QM5j3osKTCXprhiv+CYRzAGgmy7z9wYCXLKQ4 DKgYd6ftC0+csFs2HCBqyittjHnXFkT2Ygd7mXI/jGNvDtz70zMc9anaJocfjw== Date: Fri, 3 Apr 2026 18:24:42 +0200 From: Alexandre Belloni To: Jeremy Kerr Cc: "Datta, Shubhrajyoti" , "linux-kernel@vger.kernel.org" , "git (AMD-Xilinx)" , Frank Li , Joel Stanley , "linux-i3c@lists.infradead.org" Subject: Re: [PATCH v2] i3c: dw-i3c-master: Fix IBI count register selection for versalnet Message-ID: <20260403162442668f12b7@mail.local> References: <20260401084430.436059-1-shubhrajyoti.datta@amd.com> <5cb83afcd5340a108fd5a7346494ccf73752cc27.camel@codeconstruct.com.au> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5cb83afcd5340a108fd5a7346494ccf73752cc27.camel@codeconstruct.com.au> X-Last-TLS-Session-Version: TLSv1.3 Hello, On 02/04/2026 16:32:30+0800, Jeremy Kerr wrote: > Hi Shubhrajyoti, > > > > How are you binding the driver to this device? Are you using a unique OF > > > compatible string, or something ACPI-based? > > > > > > ... and if that can be specific to this hardware instance, would that be an > > > effective mechanism to select the IBI read method instead? > > Hi Jeremy, > > > > VersalNet currently uses the generic "snps,dw-i3c-master-1.00a" > > compatible string — there is no unique compatible string for this > > hardware instance. The DTS    entry looks like: > > > >   compatible = "snps,dw-i3c-master-1.00a"; > > You should *always* have a unique compatible string for each device > instance, if there can be any variation in behaviours from that generic > one (which you certainly do have here). > > You can still fall-back on a generic one, but using that as your only > compatible value means you can't do device-specific behaviours in your > driver, as you have just found. > > >   We could introduce a VersalNet-specific compatible with a generic fallback: > > > >   compatible = "xlnx,versalnet-dw-i3c-master", "snps,dw-i3c-master-1.00a"; > > Yes, you want that anyway. > I agree you need a VersalNet-specific compatible string. > >   and pass a quirk flag via of_device_id.data to select the IBI read method. > > Exactly, and there is already the struct dw_i3c_drvdata to help with > this. > > > However, the probe-time detection avoids having to enumerate all affected > > variants — the IC_HAS_IBI_DATA=0 configuration is a synthesizable > > option in the IP and may appear in other SoCs using the same core. > > > > Do you have a preference? If the DTS change is acceptable, I can go > > with the compatible + match-data approach > > That would certainly be my recommendation. > > If it's a synthesisable option, it may even be worth adding as a flag to > the binding definition (along with the same for other options that might > be present). This would mean you don't need a-priori knowledge of the > mapping of compatible strings to their synthesis options. > > I don't have any access to documentation on those options though, so > can't be of much help with doing that. > > > However I thought that detecting it will be helpful for backward compatible. > > Given it doesn't work at the moment, there shouldn't be any backwards > compat concerns, I think? I guess the proposed solution works as we can probe the HW to know how it was synthesised. It's good to be able to avoid having device tree properties for things we can discover. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com