mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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 --]

  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®