All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Hirst <rhirst@levanta.com>
To: Kyle McMartin <kyle@mcmartin.ca>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] cvs head arch/parisc/kernel/drivers.c issues
Date: Mon, 1 Aug 2005 14:48:44 +0100	[thread overview]
Message-ID: <20050801134844.GI5500@levanta.com> (raw)
In-Reply-To: <20050731202709.GL21753@roadwarrior.mcmartin.ca>

On Sun, Jul 31, 2005 at 04:27:09PM -0400, Kyle McMartin wrote:
> On Sun, Jul 31, 2005 at 04:23:38PM -0400, Kyle McMartin wrote:
> > static struct parisc_device *
> > next_device(struct parisc_device *padev) {
> 
> ...
> 
> > 	dev = next_device(&i);
> 
> Err, oops. The function should be next_dev, and next_device should be
> a la the one in sba_iommu.c and gsc.c.

Not tried this yet, but I'm unclear as to which problem you are
trying to fix...

a) "Found devices" display order

b) an alternative to my match_by_id() change that removed a check_dev() call

c) a fix to gscps2.c hanging my C360 (unlikely, I guess)

d) multiple of the above :-)


The old version of drivers.c had a for_each_padev() that did a depth
first walk of the tree reporting parents before children.  The new
code is reporting children before parents which is what causes (a)
above, I think.

check_dev() is used in several places now, all of which just check
for null/non-null return, so I'm not convinced that making it walk
the tree via next_dev() is right; take this for example:

static int print_one_device(struct device * dev, void * data)
{
        struct parisc_device * pdev = to_parisc_device(dev);

        if (check_dev(pdev))
                print_parisc_device(pdev);
        return 0;
}

if check_dev(pdev) might call next_dev() and return some other
pdev, does it make sense to be calling print_parisc_device() on the
original pdev?

I'm happy to poke at this some more anyway,

Richard

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

  reply	other threads:[~2005-08-01 13:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-30 23:10 [parisc-linux] cvs head arch/parisc/kernel/drivers.c issues Richard Hirst
2005-07-31  6:12 ` Kyle McMartin
2005-07-31  9:00   ` Richard Hirst
2005-07-31 18:47     ` Kyle McMartin
2005-08-01 20:02       ` Richard Hirst
2005-07-31 19:32     ` Richard Hirst
2005-07-31 19:38       ` Kyle McMartin
2005-07-31 20:01         ` Richard Hirst
2005-07-31 20:13           ` Kyle McMartin
2005-07-31 20:23           ` Kyle McMartin
2005-07-31 20:27             ` Kyle McMartin
2005-08-01 13:48               ` Richard Hirst [this message]
2005-08-01 14:53                 ` Richard Hirst

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=20050801134844.GI5500@levanta.com \
    --to=rhirst@levanta.com \
    --cc=kyle@mcmartin.ca \
    --cc=parisc-linux@lists.parisc-linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.