On Mon, Feb 04, 2008 at 10:37:37PM +0000, Adrian McMenamin wrote: > > On Mon, 2008-02-04 at 08:14 -0800, Greg KH wrote: > > On Mon, Feb 04, 2008 at 08:27:55AM +0000, Adrian McMenamin wrote: > > > > > > On Sun, 2008-02-03 at 21:29 -0800, Greg KH wrote: > > > > On Sun, Feb 03, 2008 at 08:00:47PM +0000, Adrian McMenamin wrote: > > > > > From: Adrian McMenamin > > > > > > > > > > This patch fixes the regression noted here: > > > > > http://lkml.org/lkml/2008/1/26/189 as well as whitespace issues in the > > > > > previous commit of this driver and the memory leaks noted here: > > > > > http://lkml.org/lkml/2008/2/2/143 (as well as one or two other minor > > > > > cleanups). > > > > > > > > Which portion of the patch fixes the kobject WARN_ON()? > > > > > > > > > > > > + if (mdev->registered == 0) { > > > + retval = device_register(&mdev->dev); > > > + if (retval) { > > > + printk(KERN_INFO > > > + "Maple bus: Attempt to register device" > > > + " (%x, %x) failed.\n", > > > + mdev->port, mdev->unit); > > > + maple_free_dev(mdev); > > > + mdev = NULL; > > > + return; > > > + } > > > + mdev->registered = 1; > > > + } > > > } > > > > > > > > > Specifically the check on mdev->registered > > > > So the code path could cause devices to be registered more than once? > > That seems broken, as no other bus that I know of needs such a check :( > > > > Is there a way to fix the root problem here, instead of this type of > > change? > > > > The hardware is very flaky. If I add in delays to the bus start, it will > detect the devices, but it's not brilliant. Registering an empty device > got round that problem, at the price of testing for the earlier > registration.
That sounds like you are just papering over the problem. Just delay and let the hardware settle down if needed :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
