http://permalink.gmane.org/gmane.linux.drivers.i2c hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.drivers.i2c/15240 <pre>Hello all, Attached patch adds support for secondary SMBus of AMD SB800 and new AMD FCH chipsets. The base address of secondary SMBus is different from SB700 and it is stored on similar place as SB800 primary SMBus. More verbose info: Probing function was just modified to read the SMBus base from address 0x28 or from original 0x2c. The secondary bus does not provide IRQ information. I think the SB700 has same secondary controller, so revision/IRQ information should not be printed too. This can be fixed in some other patch. Chipset datasheet can be found here: http://support.amd.com/us/Embedded_TechDocs/45482.pdf Tested on SB800 and FCH boards. Tested-by: Paul Menzel &lt;paulepanter-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org&gt; ASRock E350M1 with SB800 Signed-off-by: Rudolf Marek &lt;r.marek-/xGekIyIa4Ap1Coe8Ar9gA&lt; at &gt;public.gmane.org&gt; Thanks Rudolf </pre> Rudolf Marek 2013-05-17T22:46:05 http://permalink.gmane.org/gmane.linux.drivers.i2c/15239 <pre> Applied to for-current with Alan's ack, thanks! I couldn't apply the patch due to whitespace problems. I fixed them here because I wanted to have the patch in my very soon pull request. But please have a look. </pre> Wolfram Sang 2013-05-17T20:47:51 http://permalink.gmane.org/gmane.linux.drivers.i2c/15238 <pre> That's why I asked what "exactly" the attribute does. :-) Okay. If writing to the attribute doesn't delete the object which the attribute is attached to, then your patch is the correct approach. Alan Stern </pre> Alan Stern 2013-05-17T17:16:11 http://permalink.gmane.org/gmane.linux.drivers.i2c/15236 <pre>Hi! On 05/17/2013 05:31 PM, ext Alan Stern wrote: Well, seems that what I've described above wasn't precise enough... Actually only "bus controllers" have "delete_device" attribute. Simple devices on the bus do not have it. User write an address of the slave device to this attribute to delete it. This works fine for simple devices. In case of multiplexer (which is in turn also a "bus controller") there are nested "delete_device" attributes. So it's only possible to delete child nodes and not the controller itself, writing to its "delete_device". So from my POV, it fits to USB concept... </pre> Alexander Sverdlin 2013-05-17T16:25:27 http://permalink.gmane.org/gmane.linux.drivers.i2c/15235 <pre> If I understand you correctly, if D is an I2C multiplexer then writing to /sys/bus/i2c/devices/D/delete_device will get rid of all of D's children (and their descendants) and will also get rid of D itself -- right? That's _not_ what the USB attributes do. For example, if D is a USB hub then writing 0 to /sys/bus/usb/devices/D/bConfigurationValue will get rid of all D's descendants but will not get rid of D. Instead of doing it this way, the attribute method should call device_schedule_callback(). See commit d9a9cdfb078d. Alan Stern </pre> Alan Stern 2013-05-17T15:31:24 http://permalink.gmane.org/gmane.linux.drivers.i2c/15234 <pre>Hi! On 05/17/2013 04:42 PM, ext Alan Stern wrote: Like USB with its hubs, I2C structure could be tree-like, with I2C multiplexers. delete_device attribute removes I2C device from the subsystem, which is usually not a problem, except the case when device is a multiplexer and sub-devices should be removed first. Here we have the problem: holding a "s_active" lock on "delete_device" attribute of a parent (multiplexer) we need to delete children, but they were created with the same static attribute "delete_device". The safety of this operation is exactly the same as in USB case... Any more clever lockdep annotation is exactly not so easy... </pre> Alexander Sverdlin 2013-05-17T15:02:13 http://permalink.gmane.org/gmane.linux.drivers.i2c/15233 <pre> Can you explain this in a little more detail? Exactly what does the delete_device attribute do, when called for device D? That is, what does a write to /sys/bus/i2c/devices/D/delete_device do? Alan Stern </pre> Alan Stern 2013-05-17T14:42:44 http://permalink.gmane.org/gmane.linux.drivers.i2c/15232 <pre> FWIW on i2c-omap.c: Acked-by: Felipe Balbi &lt;balbi-l0cyMroinI0&lt; at &gt;public.gmane.org&gt; </pre> Felipe Balbi 2013-05-17T13:53:14 http://permalink.gmane.org/gmane.linux.drivers.i2c/15231 <pre>i2c: suppress lockdep warning on delete_device Since commit 846f99749ab68bbc7f75c74fec305de675b1a1bf the following lockdep warning is thrown in case i2c device is removed (via delete_device sysfs attribute) which contains subdevices (e.g. i2c multiplexer): ============================================= [ INFO: possible recursive locking detected ] 3.8.7-0-sampleversion-fct #8 Tainted: G O --------------------------------------------- bash/3743 is trying to acquire lock: (s_active#110){++++.+}, at: [&lt;ffffffff802b3048&gt;] sysfs_hash_and_remove+0x58/0xc8 but task is already holding lock: (s_active#110){++++.+}, at: [&lt;ffffffff802b3cb8&gt;] sysfs_write_file+0xc8/0x208 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(s_active#110); lock(s_active#110); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by bash/3743: #0: (&amp;buffer-&gt;mutex){+.+.+.}, at: [&lt;ffffffff802b3c3c&gt;] sysfs_write_file+0x4c/0x208 #1: </pre> Alexander Sverdlin 2013-05-17T12:56:35 http://permalink.gmane.org/gmane.linux.drivers.i2c/15230 <pre> This ended up being easier than I thought. The BMC can't be physically removed, but there is a jumper on the board to disable it. We flipped it and got a message during POST about it not being present. Additionally all IPMI functions did nothing (hung, but interruptable) which is what you'd expect. I think it really is disabled. In this state, I re-ran the previous tests, with identical results. That is: - "modprobe i2c_i801" succeeds - "modprobe i2c_i801 disable_features=0x10" succeeds - With interrupts disabled, "modprobe ics932s401" - With interrupts enabled, "modprobe ics932s401" hangs - With interrupts enabled, "i2cget 4 0x50 0x00" hangs I'll leave the BMC disabled for now in case that's important for further testing. If you need other tests run with the BMC enabled, I'll use a differen machine. Cheers, Rob. </pre> Robert Norris 2013-05-17T12:18:19 http://permalink.gmane.org/gmane.linux.drivers.i2c/15229 <pre> Applied to for-current, thanks! Rest will be reviewed later... </pre> Wolfram Sang 2013-05-17T12:17:56 http://permalink.gmane.org/gmane.linux.drivers.i2c/15228 <pre> I'd think we should trust the layer here. Fine with me for now. If somebody later has a setup where I2C slaves can be reset (e.g. via GPIO), so a complete bus reset is possible, we might need another solution, then. Thanks, Wolfram </pre> Wolfram Sang 2013-05-17T12:15:53 http://permalink.gmane.org/gmane.linux.drivers.i2c/15227 <pre> Thanks Wolfram. </pre> Josef Ahmad 2013-05-17T10:59:05 http://permalink.gmane.org/gmane.linux.drivers.i2c/15226 <pre> ^^ Hmm, no, SMI# isn't enabled. Wrong theory. </pre> Jean Delvare 2013-05-17T10:56:35 http://permalink.gmane.org/gmane.linux.drivers.i2c/15225 <pre> 00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09) 00: 86 80 9b 26 41 05 80 02 09 00 05 0c 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 41 04 00 00 00 00 00 00 00 00 00 00 14 10 dd 02 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 40: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 80 0f 01 00 00 00 00 00 Rob. </pre> Robert Norris 2013-05-17T10:27:06 http://permalink.gmane.org/gmane.linux.drivers.i2c/15224 <pre> Yes. There are no hangs when interrupts are explicitly disabled with disable_features=0x10 or when 6676a847 is reverted and the module rebuilt. Cheers, Rob. </pre> Robert Norris 2013-05-17T10:26:27 http://permalink.gmane.org/gmane.linux.drivers.i2c/15223 <pre> I think they do have a BMC (dmidecode would suggest so). I'll need to confirm this, and then get the datacentre support guys to pull it (yeah, messy - inherited machines on the other side of the world). It might take a couple of days, I'll let you know how it goes. Cheers, Rob. </pre> Robert Norris 2013-05-17T10:24:56 http://permalink.gmane.org/gmane.linux.drivers.i2c/15221 <pre> Well, the latter really is something which should never ever happen, and if it does happen it can only really be because something's screwed up in the locking in the I2C layer. The former is more probable, and I thought about that, but I don't have any good alternative solution. Given the problems I've seen, I don't think resetting the controller is really an option, because that'll likely cause the bus to lock (that's the original problem which I'm trying to solve in this patch.) The thing really does have to work according to the I2C protocol otherwise stuff goes irrecoverably wrong to the point of needing an entire system reset. </pre> Russell King - ARM Linux 2013-05-17T10:00:16 http://permalink.gmane.org/gmane.linux.drivers.i2c/15220 <pre> We could try to do something like that, I guess. The only question is how long to wait, b/c SMBus can pretty slow. But that kind of hack sounds more like something you'd do if irqs were getting sporadically lost on an otherwise correctly configured system. In this case, it sounds like there are never interrupts, but we are expecting some due to an incorrectly assuming that irqs are supported. What is different about his configuration where there would be no IRQs? Was Robert able to get the system working without hangs by disabling the IRQ feature of i2c-i801 module when it was builtin? </pre> Daniel Kurtz 2013-05-17T09:54:33 http://permalink.gmane.org/gmane.linux.drivers.i2c/15218 <pre> ... Can't we handle this more gracefully than to halt the kernel? Like WARN_ON and resetting the controller or disabling the bus or... </pre> Wolfram Sang 2013-05-17T09:51:51 http://permalink.gmane.org/gmane.linux.drivers.i2c/15217 <pre> I have no clue what the problem is nor how to investigate it, and in fact I strongly suspect that this is either a false positive or a problem in lower layers - driver core, sysfs etc. so nothing I can help with. So until someone comes with an evidence that there is an actual memory leak in the i2c-i801 driver itself I'm not going to pay any attention to your report, sorry. </pre> Jean Delvare 2013-05-17T09:47:04 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.drivers.i2c