linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Greg KH <greg@kroah.com>
Cc: Matt_Domsch@Dell.com, alan@redhat.com,
	linux-kernel@vger.kernel.org, jgarzik@redhat.com
Subject: Re: [RFC][PATCH] Dynamic PCI Device IDs
Date: Mon, 05 May 2003 01:37:52 -0400	[thread overview]
Message-ID: <3EB5F8B0.20501@pobox.com> (raw)
In-Reply-To: <20030502231558.GA16209@kroah.com>

Greg KH wrote:
> On Wed, Apr 30, 2003 at 07:39:57PM -0500, Matt_Domsch@Dell.com wrote:
> 
>>>First off, nice idea, but I think the implementation needs a bit of
>>>work.
>>
>>Thanks.  I didn't expect it to be perfect first-pass.
>>Let me answer some questions out-of-order, maybe that will help.
>>
>>
>>>>echo 1 > probe_it
>>>>Why wouldn't the writing to the new_id file cause the probe to
>>>
>>>happen immediatly?  Why wait?  So I think we can get rid of that file.
>>
>>That was my first idea, but Jeff said:
>>http://marc.theaimsgroup.com/?l=linux-kernel&m=104681922317051&w=2
>>        I think there is value in decoupling the two operations:
>>        
>>        	echo "0x0000 0x0000 0x0000 0x0000 0x0000 0x0000" >
>>.../3c59x/table
>>        	echo 1 > .../3c59x/probe_it
>>        
>>        Because you want the id table additions to be persistant in the face of
>>        cardbus unplug/replug, and for the case where cardbus card may not be
>>        present yet, but {will,may} be soon.
> 
> 
> But by adding the device ids, they will be persistant, for that driver,
> right?  Then when the device is plugged in, the core will iterate over
> the static and dynamic ids, right?  If so, I don't see how a "probe_it"
> file is needed.

Consider the case:
Device already exists, and is plugged in.  Like a standard PCI card.
Driver doesn't support PCI id, and the sysadmin uses /bin/echo to add one.

For unplugged case, you know you don't need to re-run the probe.

If you really don't want probe_it, I suppose you could re-run the 
driver's PCI probe for the cases where it is redundant.  However, my own 
preference is to let the sysadmin decide whether or not the driver's PCI 
probe should be re-run.

	Jeff





  reply	other threads:[~2003-05-05  5:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-01  0:39 [RFC][PATCH] Dynamic PCI Device IDs Matt_Domsch
2003-05-02 23:15 ` Greg KH
2003-05-05  5:37   ` Jeff Garzik [this message]
2003-05-06  0:17     ` Greg KH
2003-05-05 22:51   ` Matt Domsch
2003-05-06  0:15     ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2003-05-06  2:04 Matt_Domsch
2003-05-06  3:56 ` Greg KH
2003-05-06 16:35   ` Matt Domsch
2003-05-10  0:11     ` Greg KH
2003-05-13 21:28     ` Patrick Mochel
2003-05-13 21:33       ` Patrick Mochel
2003-04-30 21:45 Matt Domsch
2003-04-30 21:53 ` Jeff Garzik
2003-04-30 22:24 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EB5F8B0.20501@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=Matt_Domsch@Dell.com \
    --cc=alan@redhat.com \
    --cc=greg@kroah.com \
    --cc=jgarzik@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).