public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bill Crawford <billc@netcomuk.co.uk>
To: LKML <linux-kernel@vger.kernel.org>
Cc: MIDN Sean Jones <m053546@usna.edu>
Subject: Re: Possible bugs
Date: Tue, 04 Dec 2001 14:33:43 +0000	[thread overview]
Message-ID: <3C0CDEC7.20967AD5@netcomuk.co.uk> (raw)
In-Reply-To: <200112041201.fB4C14d23225@lists.us.dell.com>


> Date: 02 Dec 2001 17:29:52 -0500
> From: MIDN Sean Jones <m053546@usna.edu>
> To: linux-kernel@vger.kernel.org

> I was looking for code to cleanup and found these warnings:
...
> agpgart_be.c:524: warning: `agp_generic_create_gatt_table' defined but
> not used
> agpgart_be.c:652: warning: `agp_generic_free_gatt_table' defined but not
> used
> agpgart_be.c:700: warning: `agp_generic_insert_memory' defined but not
> used
> agpgart_be.c:758: warning: `agp_generic_remove_memory' defined but not
> used
...
> Are these functions supposed to be there or are they leftovers from
> previous modifications.

 They're used in a number of places, but some (most? all?) chipsets do
override the "generic" forms, so depending on which chipset(s) you
select in the config, some of these functions may not get used.

 Putting in an explicit "generic" AGP backend might solve the problem;
the other solution is to put #if guards around those functions.  That
strikes me as a bit messy and fragile as any new chipset might need
them, and we don't want some over-zealous hacker removing them because
they're not used by anything at the moment :o)

 Splitting the different chipsets into separate files and putting the
"generic" forms in their own "library" file is probably an option, but
it's debatable whether that file is big enough to really be worth it.

 You could move the ALi-specific code from agp_lookup_host_bridge to
agp_find_supported_device while you're at it ;o) or I might try to do
that in my copious quantities of free time.

> Thanks,
> 
> Sean Jones

-- 
/* Bill Crawford, Unix Systems Developer, Ebone (formerly GTS Netcom) */
#include <stddiscl>
const char *addresses[] = {
    "bill@syseng.netcom.net.uk", "Bill.Crawford@ebone.com",     // work
    "billc@netcomuk.co.uk", "bill@eb0ne.net"                    // home
};

       reply	other threads:[~2001-12-04 14:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200112041201.fB4C14d23225@lists.us.dell.com>
2001-12-04 14:33 ` Bill Crawford [this message]
2001-12-02 22:29 Possible bugs MIDN Sean Jones
2001-12-04  6:19 ` Ken Brownfield

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=3C0CDEC7.20967AD5@netcomuk.co.uk \
    --to=billc@netcomuk.co.uk \
    --cc=bill@eb0ne.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m053546@usna.edu \
    /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