From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.emenem.pl (cmyk.emenem.pl [217.79.154.63]) (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 A6B5B14A09E; Thu, 27 Jun 2024 11:29:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.79.154.63 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719487787; cv=none; b=TT23p0FV4fSOUF3gvxg3UfxGO34SOhh9HkDJ7188U1Hia9Z90/5Lj9Kn6YrkRFcSX4AQIVCM9R225IIKmlOWEthCW7aMS2t46plgOlsBpUy8WNOtylD8hZ2He0/r2yIkWV427jSWi5nAukuk+RkXqfX5olrDXIciWDzbIdfJBSA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719487787; c=relaxed/simple; bh=tiOzdOJNp6ZKRMHsXI8GpXUZGI0r7SB4Baz6mN7VoIg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=oeqICeZr0h8KQVYGMOLRpNNF1qTqEZU12ocqRdxSFIdm+1H9+37+iQ3KTK6QwwbU/xXuVQ+RzrRAMdW9N5+WEEIja67IsxnoblPzm6vhLnpYz3Ddpkr0usdKt3zj5AnM2tLJpLMof4v0sSi82UJJACl909Z4l1wmFC09iZIYO6o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ans.pl; spf=none smtp.mailfrom=ans.pl; dkim=pass (1024-bit key) header.d=ans.pl header.i=@ans.pl header.b=X1knxlpK; arc=none smtp.client-ip=217.79.154.63 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ans.pl Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ans.pl Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ans.pl header.i=@ans.pl header.b="X1knxlpK" X-Virus-Scanned: amavisd-new at emenem.pl Received: from [192.168.1.10] (c-98-45-176-131.hsd1.ca.comcast.net [98.45.176.131]) (authenticated bits=0) by cmyk.emenem.pl (8.17.1.9/8.17.1.9) with ESMTPSA id 45RBTH4j006413 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 27 Jun 2024 13:29:18 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ans.pl; s=20190507; t=1719487761; bh=OAR1dkJB/scQxeekWuNbHAxMyX4sPBdqtNAKZRpb41A=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=X1knxlpKKSV0bU+QboHBTRRoor8IPwrMgCKT6D3ii9KNL5fWCKfEfkxllte/9TA64 rU+iATDr08dckCJjASNozc60h0C2AIIXFYkFmRoHl4JvOGn8x+ySQAPPk9sPPVjP/r 9cGwjFXMXxV4IU8kimSqla84JrLSdBhGzmHgY4zA= Message-ID: <9541ab9f-0f13-4856-85f0-14615b77142f@ans.pl> Date: Thu, 27 Jun 2024 04:29:16 -0700 Precedence: bulk X-Mailing-List: linux-i2c@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Regression caused by "eeprom: at24: Probe for DDR3 thermal sensor in the SPD case" - "sysfs: cannot create duplicate filename" To: Guenter Roeck , Heiner Kallweit , Greg Kroah-Hartman , Bartosz Golaszewski , Geert Uytterhoeven , Wolfram Sang Cc: stable@vger.kernel.org, linux-i2c@vger.kernel.org, linux-hwmon@vger.kernel.org, Linux Kernel Mailing List References: <0dfa2919-98eb-4433-acb4-aa1830787c9b@roeck-us.net> <77c1b740-9e6d-40f7-83f0-9a949366f1c9@ans.pl> <97c497ae-44f7-4cec-b7d9-f639e4597571@roeck-us.net> <797c8371-dff3-4112-9733-4d3119670dbf@gmail.com> <5a4e1cd6-5770-423b-9a25-a0fbfd93014a@roeck-us.net> From: =?UTF-8?Q?Krzysztof_Ol=C4=99dzki?= Content-Language: en-US In-Reply-To: <5a4e1cd6-5770-423b-9a25-a0fbfd93014a@roeck-us.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 24.06.2024 at 20:45, Guenter Roeck wrote: > On 6/24/24 13:58, Heiner Kallweit wrote: > [ ... ] >> >> Too me the issue also looks like a race. According to the OP's logs: >> - jc42 at 0x18 is instantiated successfully >> - jc42 at 0x19 returns -EBUSY. This is what is expected if the device >> has been instantiated otherwise already. >> - jc42 at 0x1a returns -EEXIST. Here two instantiations of the the same >> device seem to collide. >> - jc42 at 0x1b returns -EBUSY, like at 0x19. >> >> So it looks like referenced change isn't wrong, but reveals an >> underlying issue with device instantiation races. > > It isn't just a race, though. Try to unload the at24 (or ee1004 driver > for DDR4) and load it again, and you'll see the -EBUSY errors. Problem > is that instantiating those drivers _always_ triggers the call to > i2c_new_client_device() even if the jc42 device is already instantiated. > Unloading the spd/eeprom driver doesn't unload the jc42 driver, > so -EBUSY will be seen if the spd/eeprom driver is loaded again. > > I have not been able to reproduce the backtrace with my systems, but those > are all with AMD CPUs using the piix4 driver, so timing is likely different. > Another difference is that my systems (with DDR4) use the ee1004 driver. > That driver instantiates the jc42 devices under a driver lock, so it is > guaranteed that a single instantiation doesn't interfere with other > instantiations running in parallel. Right, sorry for not mentioning this in the original report: [ 0.269013] pci 0000:00:1f.3: [8086:1c22] type 00 class 0x0c0500 [ 0.269098] pci 0000:00:1f.3: reg 0x10: [mem 0xc3a02000-0xc3a020ff 64bit] [ 0.269186] pci 0000:00:1f.3: reg 0x20: [io 0x3000-0x301f] [ 0.334962] pci 0000:00:1f.3: Adding to iommu group 7 [ 7.874736] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt $ lspci -s 0000:00:1f.3 -vvnn 00:1f.3 SMBus [0c05]: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller [8086:1c22] (rev 04) Subsystem: Dell Device [1028:04de] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-