From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752466Ab2DBKz3 (ORCPT ); Mon, 2 Apr 2012 06:55:29 -0400 Received: from mail.mev.co.uk ([62.49.15.74]:58382 "EHLO mail.mev.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752329Ab2DBKz1 (ORCPT ); Mon, 2 Apr 2012 06:55:27 -0400 X-Greylist: delayed 387 seconds by postgrey-1.27 at vger.kernel.org; Mon, 02 Apr 2012 06:55:27 EDT Message-ID: <4F798416.8040709@mev.co.uk> Date: Mon, 2 Apr 2012 11:48:54 +0100 From: Ian Abbott User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120330 Thunderbird/11.0.1 MIME-Version: 1.0 To: Greg KH CC: Gerard Snitselaar , "devel@driverdev.osuosl.org" , "fmhess@users.sourceforge.net" , Ian Abbott , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2] staging: comedi: resolve section mismatch in s626 References: <1332123921-14347-1-git-send-email-dev@snitselaar.org> <20120319030925.GB22956@perelman.Home> <20120319163103.GC3694@kroah.com> <20120319164325.GA31833@perelman.Home> <20120319224649.GA7679@perelman.Home> <20120319232656.GB6386@kroah.com> In-Reply-To: <20120319232656.GB6386@kroah.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2012-03-19 23:26, Greg KH wrote: > On Mon, Mar 19, 2012 at 03:46:49PM -0700, Gerard Snitselaar wrote: >> On Mon, Mar 19, 2012 at 09:43:25AM -0700, Gerard Snitselaar wrote: >>> On Mon, Mar 19, 2012 at 09:31:03AM -0700, Greg KH wrote: >>>> >>>> Ick, why is this loop even needed? We are only here if the pci device >>>> is present in the system so this shouldn't be needed at all, right? >>>> >>>> Or is this a bit more complex than I am making it out to be? >>>> >>>> greg k-h >>> >>> Most likely not. I will take a look at some of the other drivers in >>> comedi and see how the attach code looks there. I believe the code >>> section in hpdi_attach() was written by the same person. Unfortunately >>> I don't have a device to actually play around and see what changes are >>> doing. >>> >> >> I looked at this a bit more. It looks like they lose visibility to the >> pci_dev structure. >> >> *_probe() >> comedi_pci_auto_config() pci_dev >> comedi_auto_config() pci_dev->dev >> comedi_device_attach() ?? >> driv->attach() ??<= iterate through pci devices. >> >> Most of the examples I have looked at so far use for_each_pci_dev() to >> find the device, and s626 shortcuts it a bit by directly making calls >> to pci_get_subsys() with specific ids. They all verify they have the >> right device by checking the bus and slot that are grabbed from the >> pci_dev in comedi_pci_auto_config() and passed down. > > Ugh, surely there's a way to keep the pci dev through the > comedi_device_attach() call, right? comedi_device_attach() is also called for the COMEDI_DEVCONFIG ioctl for "manually" configuring a comedi device, and that has no idea about struct pci_dev, etc. I recently posted a series of patches that allows lower-level comedi drivers to supply separate hooks for auto-configuring PCI devices or USB devices without abusing the old "manual configuration" code paths, see . The old loop that searches the PCI bus is still needed for the "manual configuration" code path. -- -=( Ian Abbott @ MEV Ltd. E-mail: )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-