From: Robert Schiele <rschiele@uni-mannheim.de>
To: Steven Cole <elenstev@mesatop.com>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] Re: 2.4.8-pre1 build error in drivers/parport/parport_pc.c
Date: Fri, 27 Jul 2001 10:12:41 +0200 [thread overview]
Message-ID: <20010727101241.A15014@schiele.swm.uni-mannheim.de> (raw)
In-Reply-To: <01072619531103.06728@localhost.localdomain>
In-Reply-To: <01072619531103.06728@localhost.localdomain>; from elenstev@mesatop.com on Thu, Jul 26, 2001 at 07:53:11PM -0600
[-- Attachment #1: Type: text/plain, Size: 4001 bytes --]
On Thu, Jul 26, 2001 at 07:53:11PM -0600, Steven Cole wrote:
> I got the following errors building 2.4.8-pre1.
>
> parport_pc.c:257: redefinition of `parport_pc_write_data'
> /usr/src/linux-2.4.8-pre1/include/linux/parport_pc.h:45: `parport_pc_write_data' previously defined here
> parport_pc.c:262: redefinition of `parport_pc_read_data'
> /usr/src/linux-2.4.8-pre1/include/linux/parport_pc.h:53: `parport_pc_read_data' previously defined here
> ...
> make[3]: *** [parport_pc.o] Error 1
> make[3]: Leaving directory `/usr/src/linux-2.4.8-pre1/drivers/parport'
Hmm, these functions are multiply defined, namely in the c source and
in it's header file. I see no reason why someone should do this. The
problem was hidden in older kernel releases by the fact that these
functions were declared "extern __inline__" which is absolutely
nonsense in my opinion. So the solution should be to just remove these
inline functions from the c source file, which can be done with the
following simple and stupid patch.
This should be the correct solution, or did I miss the vital point?
Robert
diff -u --recursive --new-file v2.4.7/linux/drivers/parport/parport_pc.c linux/drivers/parport/parport_pc.c
--- v2.4.7/linux/drivers/parport/parport_pc.c Wed Jul 11 01:07:46 2001
+++ linux/drivers/parport/parport_pc.c Fri Jul 27 09:24:50 2001
@@ -253,94 +253,6 @@
parport_generic_irq(irq, (struct parport *) dev_id, regs);
}
-void parport_pc_write_data(struct parport *p, unsigned char d)
-{
- outb (d, DATA (p));
-}
-
-unsigned char parport_pc_read_data(struct parport *p)
-{
- return inb (DATA (p));
-}
-
-void parport_pc_write_control(struct parport *p, unsigned char d)
-{
- const unsigned char wm = (PARPORT_CONTROL_STROBE |
- PARPORT_CONTROL_AUTOFD |
- PARPORT_CONTROL_INIT |
- PARPORT_CONTROL_SELECT);
-
- /* Take this out when drivers have adapted to the newer interface. */
- if (d & 0x20) {
- printk (KERN_DEBUG "%s (%s): use data_reverse for this!\n",
- p->name, p->cad->name);
- parport_pc_data_reverse (p);
- }
-
- __parport_pc_frob_control (p, wm, d & wm);
-}
-
-unsigned char parport_pc_read_control(struct parport *p)
-{
- const unsigned char wm = (PARPORT_CONTROL_STROBE |
- PARPORT_CONTROL_AUTOFD |
- PARPORT_CONTROL_INIT |
- PARPORT_CONTROL_SELECT);
- const struct parport_pc_private *priv = p->physport->private_data;
- return priv->ctr & wm; /* Use soft copy */
-}
-
-unsigned char parport_pc_frob_control (struct parport *p, unsigned char mask,
- unsigned char val)
-{
- const unsigned char wm = (PARPORT_CONTROL_STROBE |
- PARPORT_CONTROL_AUTOFD |
- PARPORT_CONTROL_INIT |
- PARPORT_CONTROL_SELECT);
-
- /* Take this out when drivers have adapted to the newer interface. */
- if (mask & 0x20) {
- printk (KERN_DEBUG "%s (%s): use data_%s for this!\n",
- p->name, p->cad->name,
- (val & 0x20) ? "reverse" : "forward");
- if (val & 0x20)
- parport_pc_data_reverse (p);
- else
- parport_pc_data_forward (p);
- }
-
- /* Restrict mask and val to control lines. */
- mask &= wm;
- val &= wm;
-
- return __parport_pc_frob_control (p, mask, val);
-}
-
-unsigned char parport_pc_read_status(struct parport *p)
-{
- return inb (STATUS (p));
-}
-
-void parport_pc_disable_irq(struct parport *p)
-{
- __parport_pc_frob_control (p, 0x10, 0);
-}
-
-void parport_pc_enable_irq(struct parport *p)
-{
- __parport_pc_frob_control (p, 0x10, 0x10);
-}
-
-void parport_pc_data_forward (struct parport *p)
-{
- __parport_pc_frob_control (p, 0x20, 0);
-}
-
-void parport_pc_data_reverse (struct parport *p)
-{
- __parport_pc_frob_control (p, 0x20, 0x20);
-}
-
void parport_pc_init_state(struct pardevice *dev, struct parport_state *s)
{
s->u.pc.ctr = 0xc | (dev->irq_func ? 0x10 : 0x0);
--
Robert Schiele mailto:rschiele@uni-mannheim.de
Tel./Fax: +49-621-10059 http://webrum.uni-mannheim.de/math/rschiele/
[-- Attachment #2: Type: application/pgp-signature, Size: 524 bytes --]
next prev parent reply other threads:[~2001-07-27 8:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-27 1:53 Steven Cole
2001-07-27 8:12 ` Robert Schiele [this message]
2001-07-27 18:04 ` [PATCH] " Steven Cole
2001-07-28 16:39 ` Philip Blundell
2001-07-28 20:29 ` Robert Schiele
2001-07-28 21:06 ` Philip Blundell
2001-07-29 0:03 ` Robert Schiele
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=20010727101241.A15014@schiele.swm.uni-mannheim.de \
--to=rschiele@uni-mannheim.de \
--cc=elenstev@mesatop.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
all inboxes | Powered by JetHome®