* trouble building iptables-1.2.7a on 2.4.17
From: Don Cohen @ 2002-12-18 4:02 UTC (permalink / raw)
To: netfilter, netfilter-devel
(Not sure whether this should go to user or devel list.)
Below is the transcript.
iptables-1.2.7a INSTALL says requires >=2.4.4, so 2.4.17 should work,
right? INSTALL also mentions patch-o-matic, but latest patch-o-matic
README says >= 2.4.18. Does that mean I shouldn't need it or that I
have to get an earlier patch-o-matic or what?
====
[root@router2 /root]# cd iptables-1.2.7a/
[root@router2 iptables-1.2.7a]# make KERNEL_DIR=/home/user/linux-2.4.17
Making dependencies: please wait...
Extensions found:
cc -O2 -Wall -Wunused -I/home/user/linux-2.4.17/include -Iinclude/ -DIPTABLES_VERSION=\"1.2.7a\" -fPIC -o\
extensions/libipt_ah_sh.o -c extensions/libipt_ah.c
ld -shared -o extensions/libipt_ah.so extensions/libipt_ah_sh.o
cc -O2 -Wall -Wunused -I/home/user/linux-2.4.17/include -Iinclude/ -DIPTABLES_VERSION=\"1.2.7a\" -fPIC -o\
extensions/libipt_conntrack_sh.o -c extensions/libipt_conntrack.c
In file included from extensions/libipt_conntrack.c:15:
include/linux/netfilter_ipv4/ipt_conntrack.h:28: `IP_CT_DIR_MAX' undeclared here (not in a function)
include/linux/netfilter_ipv4/ipt_conntrack.h:29: `IP_CT_DIR_MAX' undeclared here (not in a function)
include/linux/netfilter_ipv4/ipt_conntrack.h:29: `IP_CT_DIR_MAX' undeclared here (not in a function)
extensions/libipt_conntrack.c: In function `parse_status':
extensions/libipt_conntrack.c:103: `IPS_EXPECTED' undeclared (first use in this function)
extensions/libipt_conntrack.c:103: (Each undeclared identifier is reported only once
extensions/libipt_conntrack.c:103: for each function it appears in.)
extensions/libipt_conntrack.c:105: `IPS_SEEN_REPLY' undeclared (first use in this function)
extensions/libipt_conntrack.c:107: `IPS_ASSURED' undeclared (first use in this function)
extensions/libipt_conntrack.c: In function `parse':
extensions/libipt_conntrack.c:202: `IP_CT_DIR_ORIGINAL' undeclared (first use in this function)
extensions/libipt_conntrack.c:259: `IP_CT_DIR_REPLY' undeclared (first use in this function)
extensions/libipt_conntrack.c: In function `print_status':
extensions/libipt_conntrack.c:364: `IPS_EXPECTED' undeclared (first use in this function)
extensions/libipt_conntrack.c:368: `IPS_SEEN_REPLY' undeclared (first use in this function)
extensions/libipt_conntrack.c:372: `IPS_ASSURED' undeclared (first use in this function)
extensions/libipt_conntrack.c: In function `matchinfo_print':
extensions/libipt_conntrack.c:420: `IP_CT_DIR_ORIGINAL' undeclared (first use in this function)
extensions/libipt_conntrack.c:440: `IP_CT_DIR_REPLY' undeclared (first use in this function)
make: *** [extensions/libipt_conntrack_sh.o] Error 1
^ permalink raw reply
* Re: [PATCH] (v3) move LOG_BUF_SIZE to header/config
From: Randy.Dunlap @ 2002-12-18 4:03 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
In-Reply-To: <3DFFCBFC.FF3C221@digeo.com>
On Tue, 17 Dec 2002, Andrew Morton wrote:
| "Randy.Dunlap" wrote:
| >
| > Changes from yesterday:
| >
| > a. use a shift value (suggested by HCH); probably still not as quite
| > as free and open as he suggested, but I had user-friendliness
| > problems with that.
| >
| > b. allow a wider range of values (HCH and James Cloos):
| > smaller added, larger can be added as needed.
| >
| > c. put common config into kernel/Kconfig and include that in each
| > arch/*/Kconfig
| >
| > More comments?
| >
|
| Well I like it. You were missing the arch/ia32/Kconfig include btw...
Ack, I've corrected that (added arch/i386/Kconfig).
Entire patch is below.
Thanks,
--
~Randy
patch_name: logbuf-configs-2552b.patch
patch_version: 2002.12.17
author: Randy Dunlap <rddunlap@osdl.org>
description: change LOG_BUF_SIZE to a config option (LOG_BUF_SHIFT)
product: linux
product_versions: 2.5.52
changelog: (a) move to a common kernel/Kconfig;
(b) use a SHIFT value (enforces power of 2, gives more choices)
URL:
requires: kconfig in 2.5.52
conflicts:
diffstat:
arch/alpha/Kconfig | 2 +
arch/arm/Kconfig | 2 +
arch/cris/Kconfig | 2 +
arch/i386/Kconfig | 2 +
arch/ia64/Kconfig | 3 ++
arch/m68k/Kconfig | 2 +
arch/m68knommu/Kconfig | 2 +
arch/mips/Kconfig | 2 +
arch/mips64/Kconfig | 2 +
arch/parisc/Kconfig | 2 +
arch/ppc/Kconfig | 2 +
arch/ppc64/Kconfig | 2 +
arch/s390/Kconfig | 2 +
arch/s390x/Kconfig | 2 +
arch/sh/Kconfig | 2 +
arch/sparc/Kconfig | 2 +
arch/sparc64/Kconfig | 2 +
arch/um/Kconfig | 2 +
arch/v850/Kconfig | 2 +
arch/x86_64/Kconfig | 2 +
kernel/Kconfig | 55 +++++++++++++++++++++++++++++++++++++++++++++++++
kernel/printk.c | 11 ---------
22 files changed, 97 insertions(+), 10 deletions(-)
--- ./arch/m68k/Kconfig%LOGBUF Sun Dec 15 18:08:11 2002
+++ ./arch/m68k/Kconfig Tue Dec 17 14:08:33 2002
@@ -2346,3 +2346,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/sparc/Kconfig%LOGBUF Sun Dec 15 18:07:42 2002
+++ ./arch/sparc/Kconfig Tue Dec 17 14:11:06 2002
@@ -1422,3 +1422,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/sparc64/Kconfig%LOGBUF Sun Dec 15 18:08:16 2002
+++ ./arch/sparc64/Kconfig Tue Dec 17 14:11:13 2002
@@ -1710,3 +1710,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/i386/Kconfig%LOGBUF Sun Dec 15 18:07:47 2002
+++ ./arch/i386/Kconfig Tue Dec 17 11:38:46 2002
@@ -1610,3 +1610,5 @@
bool
default y
+source "kernel/Kconfig"
+
--- ./arch/ppc/Kconfig%LOGBUF Sun Dec 15 18:08:23 2002
+++ ./arch/ppc/Kconfig Tue Dec 17 14:10:18 2002
@@ -1872,3 +1872,5 @@
source "crypto/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/m68knommu/Kconfig%LOGBUF Sun Dec 15 18:08:13 2002
+++ ./arch/m68knommu/Kconfig Tue Dec 17 14:08:52 2002
@@ -759,3 +759,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/alpha/Kconfig%LOGBUF Sun Dec 15 18:08:14 2002
+++ ./arch/alpha/Kconfig Tue Dec 17 14:07:34 2002
@@ -1030,3 +1030,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/cris/Kconfig%LOGBUF Sun Dec 15 18:08:19 2002
+++ ./arch/cris/Kconfig Tue Dec 17 14:08:06 2002
@@ -759,3 +759,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/mips/Kconfig%LOGBUF Sun Dec 15 18:07:56 2002
+++ ./arch/mips/Kconfig Tue Dec 17 14:08:59 2002
@@ -1284,3 +1284,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/x86_64/Kconfig%LOGBUF Sun Dec 15 18:08:14 2002
+++ ./arch/x86_64/Kconfig Tue Dec 17 14:11:54 2002
@@ -700,3 +700,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/ppc64/Kconfig%LOGBUF Sun Dec 15 18:08:09 2002
+++ ./arch/ppc64/Kconfig Tue Dec 17 14:10:25 2002
@@ -559,3 +559,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/um/Kconfig%LOGBUF Sun Dec 15 18:07:57 2002
+++ ./arch/um/Kconfig Tue Dec 17 14:11:35 2002
@@ -171,3 +171,5 @@
endmenu
+source "kernel/Kconfig"
+
--- ./arch/arm/Kconfig%LOGBUF Sun Dec 15 18:08:09 2002
+++ ./arch/arm/Kconfig Tue Dec 17 14:07:56 2002
@@ -1228,3 +1228,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/parisc/Kconfig%LOGBUF Sun Dec 15 18:08:11 2002
+++ ./arch/parisc/Kconfig Tue Dec 17 14:10:11 2002
@@ -423,3 +423,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/ia64/Kconfig%LOGBUF Sun Dec 15 18:08:21 2002
+++ ./arch/ia64/Kconfig Tue Dec 17 14:08:24 2002
@@ -891,3 +891,6 @@
source "security/Kconfig"
source "crypto/Kconfig"
+
+source "kernel/Kconfig"
+
--- ./arch/mips64/Kconfig%LOGBUF Sun Dec 15 18:07:52 2002
+++ ./arch/mips64/Kconfig Tue Dec 17 14:09:07 2002
@@ -727,3 +727,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/s390x/Kconfig%LOGBUF Sun Dec 15 18:07:59 2002
+++ ./arch/s390x/Kconfig Tue Dec 17 14:10:41 2002
@@ -346,3 +346,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/v850/Kconfig%LOGBUF Sun Dec 15 18:07:56 2002
+++ ./arch/v850/Kconfig Tue Dec 17 14:11:46 2002
@@ -452,4 +452,6 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
#############################################################################
--- ./arch/sh/Kconfig%LOGBUF Sun Dec 15 18:08:23 2002
+++ ./arch/sh/Kconfig Tue Dec 17 14:10:52 2002
@@ -1276,3 +1276,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./arch/s390/Kconfig%LOGBUF Sun Dec 15 18:07:54 2002
+++ ./arch/s390/Kconfig Tue Dec 17 14:10:33 2002
@@ -337,3 +337,5 @@
source "lib/Kconfig"
+source "kernel/Kconfig"
+
--- ./kernel/Kconfig%LOGBUF Tue Dec 17 14:00:31 2002
+++ ./kernel/Kconfig Tue Dec 17 14:28:52 2002
@@ -0,0 +1,55 @@
+# This general setup config file is read _after_ all other config files.
+# It is for generic kernel options that cannot be handled elsewhere,
+# including some generic options that are processor-dependent.
+# This is also _not_ for device driver options.
+# They should be handled in their driver subsystem areas.
+
+menu "Common kernel setup (more)"
+
+choice
+ prompt "Kernel log buffer size"
+ default LOG_BUF_SHIFT_17 if ARCH_S390
+ default LOG_BUF_SHIFT_16 if X86_NUMAQ || IA64
+ default LOG_BUF_SHIFT_15 if SMP
+ default LOG_BUF_SHIFT_14
+ help
+ Select kernel log buffer size from this list (power of 2).
+ Defaults: 17 (=> 128 KB for S/390)
+ 16 (=> 64 KB for x86 NUMAQ or IA-64)
+ 15 (=> 32 KB for SMP)
+ 14 (=> 16 KB for uniprocessor)
+
+config LOG_BUF_SHIFT_17
+ bool "128 KB"
+ default y if ARCH_S390
+
+config LOG_BUF_SHIFT_16
+ bool "64 KB"
+ default y if X86_NUMAQ || IA64
+
+config LOG_BUF_SHIFT_15
+ bool "32 KB"
+ default y if SMP
+
+config LOG_BUF_SHIFT_14
+ bool "16 KB"
+
+config LOG_BUF_SHIFT_13
+ bool "8 KB"
+
+config LOG_BUF_SHIFT_12
+ bool "4 KB"
+
+endchoice
+
+config LOG_BUF_SHIFT
+ int
+ default 17 if LOG_BUF_SHIFT_17=y
+ default 16 if LOG_BUF_SHIFT_16=y
+ default 15 if LOG_BUF_SHIFT_15=y
+ default 14 if LOG_BUF_SHIFT_14=y
+ default 13 if LOG_BUF_SHIFT_13=y
+ default 12 if LOG_BUF_SHIFT_12=y
+
+endmenu
+
--- ./kernel/printk.c%LOGBUF Sun Dec 15 18:08:24 2002
+++ ./kernel/printk.c Tue Dec 17 14:01:50 2002
@@ -30,16 +30,7 @@
#include <asm/uaccess.h>
-#if defined(CONFIG_X86_NUMAQ) || defined(CONFIG_IA64)
-#define LOG_BUF_LEN (65536)
-#elif defined(CONFIG_ARCH_S390)
-#define LOG_BUF_LEN (131072)
-#elif defined(CONFIG_SMP)
-#define LOG_BUF_LEN (32768)
-#else
-#define LOG_BUF_LEN (16384) /* This must be a power of two */
-#endif
-
+#define LOG_BUF_LEN (1 << CONFIG_LOG_BUF_SHIFT) /* This must be a power of two */
#define LOG_BUF_MASK (LOG_BUF_LEN-1)
#ifndef arch_consoles_callable
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-18 4:07 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ulrich Drepper, Nakajima, Jun, Matti Aarnio, Hugh Dickins,
Dave Jones, Ingo Molnar, linux-kernel
In-Reply-To: <3DFFED33.2020201@transmeta.com>
Btw, on another tangent - Andrew Morton reports that APM is unhappy about
the fact that the fast system call stuff required us to move the segments
around a bit. That's probably because the APM code has the old APM segment
numbers hardcoded somewhere, but I don't see where (I certainly knew about
the segment number issue, and tried to update the cases I saw).
Debugging help would be appreciated, especially from somebody who knows
the APM code.
Linus
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-18 4:05 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ulrich Drepper, Nakajima, Jun, Matti Aarnio, Hugh Dickins,
Dave Jones, Ingo Molnar, linux-kernel
In-Reply-To: <3DFFED33.2020201@transmeta.com>
On Tue, 17 Dec 2002, H. Peter Anvin wrote:
> Ulrich Drepper wrote:
> >
> > That's good to know but not what I meant.
> >
> > I referred to syscall/sysret opcodes. They are broken in their own way
> > (destroying ecx on kernel entry) but at least they preserve eip.
> >
>
> Destroying %ecx is a lot less destructive than destroying %eip and %esp...
Actually, as far as the kernel is concerned, they are about equally bad.
Destroying %eip is the _least_ bad register to destroy, since the kernel
can control that part, and it is trivial to just have a single call site.
But destroying %esp or %ecx is pretty much totally equivalent - it
destroys one user mode register, and it doesn't really matter _which_ one.
In both cases 32 bits of user information is destroyed, and they are 100%
equivalent as far as the kernel is concerned.
On intel with sysenter, destroying %esp means that we have to save the
value in %ebp, and we thus lose argument 6.
On AMD, %ecx is destroyed on entry, which means that we lose argument 2
(which i smore important than arg6, but that only means that the AMD
trampoline will have to move the old value of %ecx into %ebp, at which
point the two approaches are again exactly the same).
In either case, one GP register is irrevocably lost, which means that
there are only 5 GP registers left for arguments. And thus both Intel and
AMD will have _exactly_ the same problem with six-argument system calls.
The _sane_ thing to do would have been to save the old user %esp/%eip on
the kernel stack. Preferably together with %eflags and %ss and %cs, just
for completeness. That stack save part is _not_ the expensive or complex
part of a "int 0x80" or long call (the _complex_ part is all the stupid
GDT/IDT lookups and all the segment switching crap).
In short, both AMD and Intel optimized away too much.
The good news is that since both of them suck, it's easier to make the
six-argument decision. Since six arguments are problematic for all major
"fast" system calls, my executive decision is to just say that
six-argument system calls will just have to continue using the old and
slower system call interface. It's kind of a crock, but it's simply due to
silly CPU designers.
Linus
^ permalink raw reply
* Re: MSN helper module
From: Octavio / Super @ 2002-12-18 3:46 UTC (permalink / raw)
To: Carlos Fernandez Sanz; +Cc: netfilter-devel
In-Reply-To: <002201c2a630$5c460950$152ea8c0@maincomp>
Carlos:
Bauke Fahner and I started working on something, but couldn't get much actually done.
At 01:56 a.m. 18/12/2002 +0100, Carlos Fernandez Sanz wrote:
>Filip,
>
>I need to check the protocol specs (and even more important, I need to see
>some actual data flow) a bit more in detail before getting into any deep
>discussion, but I believe it's better to focus on a working implementation
>and then tight the security with all the checks that might be needed.
I completely agree with that.
>I'm reading some docs and they say that for a file transfer to take place,
>you need to send an invitation message over a switchboard session. It
>doesn't say whether such a session can be an existing one or not, the
>example opens one so I can't really tell.
I don't actually think it should be that difficult. The thing is that I haven't understood some part of the Netfilter documentation, but here is my opinion.
With the current implementation of MSNP and Netfilter, you only need to do conntrack and nat for outgoing file transfers.
Since in the current protocol implementation, switchboard sessions will always be opened on port 1863, my idea is to capture this port and start the connection tracking from here.
As for NAT, we should only need to do the same thing: Accepted packets should be analyzed and checked to see whether the packet is asking the client for information, and, on the reply packet change the port number and IP address accordingly (and update the rest of the packet accordingly, also).
>BTW...and I'm saying this without careful documentation reading...the
>protocol seems 'secure enough' :-)
>
>Anyway, if you are up for a challenge, I'll let you know as soon as I have
>something working and you can have some fun trying to break it :-)
I'm in. I have the rest of December and the whole January.
Octavio.
---
/**************************************************
Octavio Alvarez (aka: Super, Doogie)
ICQ# 42020731. MSN_ID: alvarezp2000@h0tmail.com
**************************************************/
^ permalink raw reply
* Re: Printer error (errata)
From: Bill Pleasants @ 2002-12-18 3:44 UTC (permalink / raw)
To: Ray Olszewski; +Cc: linux-newbie
In-Reply-To: <5.1.0.14.1.20021216085528.02134570@celine>
My previous message got truncated. I hope this gets through.
Ray Olszewski wrote:
> You don't give us much to go on, but since the problems seem to be
> with name resolution, I'd suggest you tell us the details of your
> system as they relate to that.
>
> First is your networking setup. Are you connected to a LAN or directly
> to the internet? (I guess you must be if you are using MapQuest.) If
> so, how?
This is a LANless computer connected to the internet by a 56K modem.
>
> More immediately, how does your system do name-to-address resolution?
> Does it rely on /etc/hosts? If so, what are the contents of that file?
> Or does it use a nameserver? If so, is it accessable? And what are the
> contents of the /etc/resolv.conf file?
I have some notion of what name-to-address resolution is for the
internet but not what it is for the Linux OS. /etc/hosts contains:
"# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain
>
> Does the message really say "local host" rather than "localhost"? What
> result do you get if (from the command line) you try "ping localhost"?
This is cut and paste:
"[bill@localhost bill]$ lprm
Get_local_host: 'localhost' IP address not available!"
"[bill@localhost bill]$ ping localhost
ping: unknown host localhost"
>
> How is the printer connected to the PC? Parallel port? Something else?
Parallel port.
>
> Although your questions involve generic Linux applications, the form
> of your report is specific to RH 8.0. My questions ask for more
> generic Linux information, which will permit non-RH users to try to
> assess your problem. If you prefer to stick with the RH tools, that's
> fine ... in that case, I hope someone else here, someone who does use
> RH 8.0, pops in with translations of these suggestions to Red Hat-ese.
I have no preference for RH other than that it was recommended and I was
given a copy.
>
> Finally, as to your immediate problem ... if the third page of a
> epecific document continues to fail to print, while other docs print
> fine (do they? you haven't said), i'd suspect something odd about the
> specific document. Generically, you need to investigate how general
> the printing problem is before we can tackle it systematically.
I did not retain the file I first tried to print. Additional attempts
to print have produced no response from the printer. Thank you for your
offer to help.
>
> At 10:14 PM 12/15/02 -0500, Bill Pleasants wrote:
>
>> Hello,
>> After installing RH 8.0 in my HP Pentium II, my first successful
>> installation,
>> I installed a Brother HL-720 printer. I set it up local. The Printer
>> Administration window shows:
>> Command: lpr
>>
>> Driver: Generic Printer (SGENPRT)
>>
>> Location:
>>
>> After printing 2 of 3 pages from
>> Mapquest, the printer indicated toner out. I replaced the cartridge and
>> there was an error light which can be cleared by unplugging the printer
>> cable and cycling the printer off. I reset the print queue and the same
>> 2 pages printed and the error light flashed. Rebooted - same error
>> light.
>> Attempts to print additional items failed. Later I entered "lprm" to
>> cancel anything pending and got
>> "local host IP not available." When I entered
>> "/etc/init.d/lpd stop" I got "[FAILED]"
>> I repeated it and got
>> "[FAILED]"
>> "local host IP not available"
>> In the panel is a ? which when clicked gives
>> "Temporary error in name resolution."
>> So far I haven't learned what this IP is about. I would appreciate help.
>
>
>
> --
> -------------------------------------------"Never tell me the
> odds!"--------
> Ray Olszewski -- Han Solo
> Palo Alto, California, USA ray@comarre.com
> -------------------------------------------------------------------------------
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* RE: [ANNOUNCE] Intel PRO/100 software developer manual released
From: Feldman, Scott @ 2002-12-18 3:46 UTC (permalink / raw)
To: 'Anton Blanchard'; +Cc: linux-kernel, netdev, LOSTeam
> Nice work guys! This has already answered a few questions I
> had when tuning the e100 on ppc64.
Great! Let us know if you figure out that checksum weirdness you saw the
other day.
> Any plans to release similar docs for the e1000?
It's a logical next step, but no definitive schedule. Let's just leave it
as a goal.
-scott
^ permalink raw reply
* Re: slave_destroy called in scsi_scan.c:scsi_probe_and_add_lun()
From: Doug Ledford @ 2002-12-18 3:35 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: linux-scsi
In-Reply-To: <955680000.1040177254@aslan.btc.adaptec.com>
On Tue, Dec 17, 2002 at 07:07:34PM -0700, Justin T. Gibbs wrote:
> I decided to instrument what the SCSI layer does with these calls before
> looking at refcounting. Here's the output of the scan of a bus with
> two drives on it: id 0 and id 1.
>
> scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.23
> <Adaptec aic7899 Ultra160 SCSI adapter>
> aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
>
> scsi0: Slave Alloc 0
This is the initial scsi_alloc_sdev() slave_alloc() call.
> scsi0: Slave Destroy 0
> scsi0: Slave Alloc 0
This pair is the first time through the probe_and_add_lun() routine where
we destroy the old slave and alloc a new one because, all except for this
first time through, we will be updating the device number. We also send
the actual INQUIRY command in between this alloc and the alloc below.
> scsi0: Slave Alloc 0
We alloc the new sdev here and copy the stuff from the scan sdev into it.
> Vendor: SEAGATE Model: ST39236LWV Rev: 0010
> Type: Direct-Access ANSI SCSI revision: 03
Print the info.
> scsi0: Slave Destroy 0
> scsi0: Slave Alloc 0
I think, but I'm not positive, that this extra Destroy/Alloc pair is from
the attempt to scan for lun information.
> scsi0: Slave Destroy 1
> scsi0: Slave Alloc 1
And here's the gotcha. The destroy call you see points to 1 because we
have already updated the sdev->target value in place before calling
destroy. In my case, it's a simple kfree() that doesn't care about what
number or anything else, it knows what to kfree() simply by grabbing
sdev->hostdata. Then we alloc a struct for 1 which is the next device to
be scanned. The rest of this is pretty much a straight repeat of events.
> ...
>
> scsi0: Slave Configure 0
> scsi0: Slave Configure 1
>
> Notice that for all IDs but 0, a slave destroy call is performed
> prior to any slave allocations. Very nice. Note that I wasn't
> complaining that I couldn't work around this kind of crap, just
> that this crap is unsettling. 8-)
I stared at the scsi_scan.c code for a full day, did about 3 rewrites and
threw them all away half way through each time before I finally gave in
and left the scan code as much alone as I could. But, I think I have the
answer.
I'm headed to a midnight showing of the Two Towers in 30 minutes (OK, the
movie isn't for an hour and a half, but I'm meeting friends at the local
coffee shop to sit around and bullshit until it starts), but when I
get home from that I'll see if I can't get my idea coded up and out
before I crash. Assuming I do, you will get exactly one alloc per
channel/target/lun value scanned, exactly one configure per device found
(although still delayed like it is now), and exactly one immediate destroy
per device alloced and not found and exactly one destroy immediately
prior to device free at the mid layer level (and this time all the destroy
events will come after the corresponding alloc :-)
> > In my driver I don't attempt to do anything like send cache flush
> > commands or the like, so I don't have the shutdown difficulties you do
> > and things work quite nicely.
>
> It's not about cache flushing or anything else. It's about knowing if
> you need to retest the connection to a device, whether or not you should
> force a renegotiation the next time a command is attempted to a device,
> etc. etc. So, when linux tells the driver that the device is gone,
> we setup our state so that we will not trust the old negotiated values
> and will perform Domain Validation again should the device return.
It's coming together well enough in my mind now that I'm 99% positive
you'll have this by tomorrow morning.
/me pulls bk latest so he can get a small start before leaving
--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-18 3:36 UTC (permalink / raw)
To: Ulrich Drepper
Cc: Nakajima, Jun, Linus Torvalds, Matti Aarnio, Hugh Dickins,
Dave Jones, Ingo Molnar, linux-kernel
In-Reply-To: <3DFFD55E.6020305@redhat.com>
Ulrich Drepper wrote:
>
> That's good to know but not what I meant.
>
> I referred to syscall/sysret opcodes. They are broken in their own way
> (destroying ecx on kernel entry) but at least they preserve eip.
>
Destroying %ecx is a lot less destructive than destroying %eip and %esp...
-hpa
^ permalink raw reply
* Re: USB PCI
From: dashielljt @ 2002-12-18 3:26 UTC (permalink / raw)
To: Korosi Akos; +Cc: Newbie
In-Reply-To: <20021217094200.13045.qmail@web2.mailbox.hu>
Correction on that date. The bios needs to be no younger than july 1,
1999. Anything newer actually does support at least usb 1 and maybe usb
2.
Jude <dashielljt(at)gmpexpress-dot-net>
On Tue, 17 Dec 2002, Korosi Akos wrote:
Hi!
dashielljt <dashielljt@gmpexpress.net> wrote:
>Here's your problem. You must have a bios on that computer that has a
> date on or after July 1, 1989.
...
> Jude <dashielljt(at)gmpexpress-dot-net>
Thanks! And if the bios is newer, than this date
(I could check this only in weekend), then
there are no other problems?
Akos
________________________________________________
http://mailbox.hu - Már SMS értesítéssel is!
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: Printer error
From: Bill Pleasants @ 2002-12-18 3:25 UTC (permalink / raw)
To: Ray Olszewski; +Cc: linux-newbie
In-Reply-To: <5.1.0.14.1.20021216085528.02134570@celine>
Ray Olszewski wrote:
> You don't give us much to go on, but since the problems seem to be
> with name resolution, I'd suggest you tell us the details of your
> system as they relate to that.
>
> First is your networking setup. Are you connected to a LAN or directly
> to the internet? (I guess you must be if you are using MapQuest.) If
> so, how?
This is a LANless computer connected to the internet by a 56K modem.
>
> More immediately, how does your system do name-to-address resolution?
> Does it rely on /etc/hosts? If so, what are the contents of that file?
> Or does it use a nameserver? If so, is it accessable? And what are the
> contents of the /etc/resolv.conf file?
I have some notion of what name-to-address resolution is for the
internet but not what it is for the Linux OS. /etc/hosts contains:
"# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* How do I see all my partitions?
From: Chris @ 2002-12-18 3:23 UTC (permalink / raw)
To: linux-newbie
Hi, I'm a new Red Hat user and want to mount
my winxp partition. How do I display all the
partitions, Win/Dos/Linux, in one place so I can
give mount the correct partition name?
Thank you,
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: slave_destroy called in scsi_scan.c:scsi_probe_and_add_lun()
From: Luben Tuikov @ 2002-12-18 3:22 UTC (permalink / raw)
To: Andrew Morton
Cc: Doug Ledford, Christoph Hellwig, Justin T. Gibbs, linux-scsi
In-Reply-To: <3DFFCDC0.C456BBDB@digeo.com>
Andrew Morton wrote:
>
[...]
> So I expect that in practice we would be unlikely to go beyond
> 128 requests per direction per queue. But it should be an
> option, and it should work well.
I have an actual number: 512*. This is the number which /proc/slabinfo
tells me, and I suspect that the number of active (LLDD owner) commands
is a lot less than this.**
* I get this number when writing (I->T) just over 100 GiB file,
using a ``mini'' scsi-core which I wrote for a project at work.
And this, 512, number is the largest value I've seen so far,
i.e. the largest pool.
** I can actually obtain the exact (average) number of active commands
but I don't think that there's any need to. (QED)
But, yes, using the slab allocator (with the appropriate flags(!), etc...)
isn't a bad idea at all.
--
Luben
^ permalink raw reply
* [LARTC] iptables mangle & iproute
From: Arindam Haldar @ 2002-12-18 3:22 UTC (permalink / raw)
To: lartc
i all,
an extract of my rule tables...
40: from all to 203.x.x.64/25 lookup TABLEa
40: from all fwmark 40 lookup TABLEa
50: from 203.x.x.0/24 lookup TABLEb
iptables mangles are as follows..
root@ICG:root# iptables -nvL -t mangle
Chain PREROUTING (policy ACCEPT 7995K packets, 2646M bytes)
pkts bytes target prot opt in out source destination
85 6908 MARK all -- * * 0.0.0.0/0 203.x.x.64/25
MARK set 0x40
Chain INPUT (policy ACCEPT 526K packets, 252M bytes)
pkts bytes target prot opt in out source destination
0 0 MARK all -- * * 203.x.x.64/29 0.0.0.0/0
MARK set 0x40
im not able to find the problem for why i cant trace or ping to
203.x.x.64/25 network and vice-versa.
i want to add that all forwading rule are there.. it was working when i
didnt used _fwmark_ ..want to use fwmark for policy routing...
one last but not least things to ask is --> _marking_ based policy
routing a good solution that one without _marking_ ???
thanking in advance...
A.H
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [ANNOUNCE] Intel PRO/100 software developer manual released
From: Anton Blanchard @ 2002-12-18 3:27 UTC (permalink / raw)
To: Feldman, Scott; +Cc: linux-kernel, netdev, LOSTeam
In-Reply-To: <288F9BF66CD9D5118DF400508B68C44604758F6C@orsmsx113.jf.intel.com>
> Available at https://sourceforge.net/projects/e1000.
>
> The full title is:
>
> Intel 8255x 10/100 Mbps Ethernet Controller Family
> Open Source Software Developer Manual
> Revision 1.0
>
> The manual is intended to support the maintenance of the e100 driver (or the
> best driver for the PRO/100 networking hardware ;-). The manual covers the
> 82557, 82558, 82559, 82550, and 82551 Ethernet controllers.
Nice work guys! This has already answered a few questions I had when
tuning the e100 on ppc64.
Any plans to release similar docs for the e1000?
Anton
^ permalink raw reply
* iptables mangle & iproute
From: Arindam Haldar @ 2002-12-18 3:11 UTC (permalink / raw)
To: NETFILTER
i all,
an extract of my rule tables...
40: from all to 203.x.x.64/25 lookup TABLEa
40: from all fwmark 40 lookup TABLEa
50: from 203.x.x.0/24 lookup TABLEb
iptables mangles are as follows..
root@ICG:root# iptables -nvL -t mangle
Chain PREROUTING (policy ACCEPT 7995K packets, 2646M bytes)
pkts bytes target prot opt in out source destination
85 6908 MARK all -- * * 0.0.0.0/0 203.x.x.64/25
MARK set 0x40
Chain INPUT (policy ACCEPT 526K packets, 252M bytes)
pkts bytes target prot opt in out source destination
0 0 MARK all -- * * 203.x.x.64/29 0.0.0.0/0
MARK set 0x40
im not able to find the problem for why i cant trace or ping to
203.x.x.64/25 network and vice-versa.
i want to add that all forwading rule are there.. it was working when i
didnt used _fwmark_ ..want to use fwmark for policy routing...
one last but not least things to ask is --> _marking_ based policy
routing a good solution that one without _marking_ ???
thanking in advance...
A.H
^ permalink raw reply
* Re: [RFT][PATCH] generic device DMA implementation
From: David Mosberger @ 2002-12-18 3:13 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-kernel
In-Reply-To: <200212180301.gBI31wE06794@localhost.localdomain>
James> The attached should represent close to final form for the
James> generic DMA API. It includes documentation (surprise!) and
James> and implementation in terms of the pci_ API for every arch
James> (apart from parisc, which will be submitted later).
James> I've folded in the feedback from the previous thread.
James> Hopefully, this should be ready for inclusion. If people
James> could test it on x86 and other architectures, I'd be
James> grateful.
James> comments and feedback from testing welcome.
Would you mind doing a s/consistent/coherent/g? This has been
misnamed in the PCI DMA interface all along, but I didn't think it's
worth breaking drivers because of it. But since this is a new
interface, there is no such issue.
(Consistency says something about memory access ordering, coherency
only talks about there not being multiple values for a given memory
location. On DMA-coherent platforms with weakly-ordered memory
systems, the returned memory really is only coherent, not consistent,
i.e., you have to use memory barriers if you want to enforce
ordering.)
Thanks,
--david
^ permalink raw reply
* fbmem.c - fb_mmap
From: Jon Smirl @ 2002-12-18 3:01 UTC (permalink / raw)
To: linux-fbdev-devel
fb_mmap contains an ifdef for every architecture on
Linux. Is it possible to implement this using
something like ioremap_nocache() and avoid the ifdefs?
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: serial.c fix: ELAN fix breaks others
From: Matthew Locke @ 2002-12-18 2:58 UTC (permalink / raw)
To: Ed Vance; +Cc: 'Rusty Russell', Russell King, 'linux-serial'
In-Reply-To: <11E89240C407D311958800A0C9ACF7D1A33D01@EXCHANGE>
Ed Vance wrote:
>On Mon, December 16, 2002 at 6:18 PM, Matthew Locke wrote:
>
>>Ed Vance wrote:
>>
>>>>From: Matthew Locke [mailto:mlocke@mvista.com]
>>>>
>>>On Mon, December 16, 2002 at 4:29 PM, Matthew Locke wrote:
>>>
>>>>Ed Vance wrote:
>>>>
>>>>>[ snip ]
>>>>>
>>>>>I avoided the #ifdef by applying the workaround only to
>>>>>UARTs detected as the "simple" types. The AMD Elan's UARTs
>>>>>detect as type 16550A. I don't know (yet) of any "simple"
>>>>>UARTs that misbehave when exposed to the Elan work-around.
>>>>>See the comments above the patch.
>>>>>
>>>>Ed,
>>>>
>>>>I think I have one. In general I would prefer not to include
>>>>workarounds for unaffected platforms. In the embedded world,
>>>>I always seem to run into the platform on which these
>>>>workarounds cause problems:( Can we add:
>>>>
>>>>#ifndef CONFIG_MELAN
>>>>define uart_transmit_ready 0
>>>>#endif
>>>>
>>>>to your patch?
>>>>
>>>Hi Matthew,
>>>
>>>Of course, I would prefer not to introduce an #ifdef that is
>>>not necessary. However, running properly on the Elan platform
>>>already requires rebuilding the kernel with CONFIG_MELAN
>>>defined to express Elan specific kernel code. So, use of the
>>>define in the serial driver would not cause anybody an extra
>>>build step ...
>>>
>>>If we have to introduce an #ifdef to get correct function on
>>>unbroken hardware, then we should. Of course, we would want
>>>to follow the coding guidelines about where to hide the #ifdef.
>>>
>>>Please tell me:
>>>
>>>What UART flavor are you jousting with?
>>>
>>The TI OMAP on-chip 16650.
>>
>>>
>>>Which UART type does the serial driver detect?
>>>
>>Typically the serial driver doesn't "detect" the type for
>>these on-chip devices. Instead we pass in the type with
>>the STD_SERIAL_PORT_DEFN defined in the arch code. This
>>one is a 16650 with a few special tweaks for OMAP. So we
>>setup a PORT_OMAP port type and guarantee the new type is
>>greater than PORT_16550A. However, I'm still concerned
>>about chips that will report < 16550A port types and may
>>have problems with the work around.
>>
>>>
>>>What is the specific errant behavior?
>>>
>>The same as described in your comments- dropped xmit data.
>>
>
>Hi Matthew,
>
>I read the TI OMAP UART doc. It says the UART type emulated by the
>OMAP is 16750 (type 8), instead of 16650. Even 16650 (type 6) is
>out of the range exposed to the work-around. It does not yet sound
>like this is a type 1 - 4 UART that the work-around breaks. The
>issue seems to pivot on the default types defined in
>STD_SERIAL_PORT_DEFN.
>
oh, good.
>
>
>I would at least like to preserve the work-around code on the x86
>architecture so a vanilla x86 distro or rescue disk would boot and
>be at least minimally usable on the Elan with a serial console.
>
Absolutely.
>
>
>Which kernel source should I download and look at so I would see the
>same defs that you are working with?
>
We are still working on moving OMAP to the lastest kernel and cleaning
up the port. I believe there a snapshot at ftp://source.mvista.com.
>
>
>(I'm not saying no to an #ifdef. I just don't think I have completed
>the due diligence yet.)
>
ok. I'm going to use your fix and see what happens on some of our
boards with on-chip 16550's.
>
>
>Best regards,
>Ed
>
>----------------------------------------------------------------
>Ed Vance edv (at) macrolink (dot) com
>Macrolink, Inc. 1500 N. Kellogg Dr Anaheim, CA 92807
>----------------------------------------------------------------
>
>
^ permalink raw reply
* [RFT][PATCH] generic device DMA implementation
From: James Bottomley @ 2002-12-18 3:01 UTC (permalink / raw)
To: linux-kernel; +Cc: James.Bottomley
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]
The attached should represent close to final form for the generic DMA API. It
includes documentation (surprise!) and and implementation in terms of the pci_
API for every arch (apart from parisc, which will be submitted later).
I've folded in the feedback from the previous thread. Hopefully, this should
be ready for inclusion. If people could test it on x86 and other
architectures, I'd be grateful.
comments and feedback from testing welcome.
James
[-- Attachment #2: tmp.diff --]
[-- Type: text/plain , Size: 39112 bytes --]
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.859 -> 1.861
# arch/i386/kernel/pci-dma.c 1.8 -> 1.10
# drivers/pci/pci.c 1.51 -> 1.52
# include/asm-i386/pci.h 1.17 -> 1.18
# include/linux/pci.h 1.55 -> 1.56
# Documentation/DMA-mapping.txt 1.13 -> 1.14
# arch/i386/kernel/i386_ksyms.c 1.40 -> 1.41
# (new) -> 1.1 include/asm-s390x/dma-mapping.h
# (new) -> 1.1 include/asm-arm/dma-mapping.h
# (new) -> 1.1 include/asm-sparc/dma-mapping.h
# (new) -> 1.1 include/asm-cris/dma-mapping.h
# (new) -> 1.1 include/asm-sh/dma-mapping.h
# (new) -> 1.1 include/asm-ppc64/dma-mapping.h
# (new) -> 1.1 include/asm-m68knommu/dma-mapping.h
# (new) -> 1.1 Documentation/DMA-API.txt
# (new) -> 1.1 include/asm-um/dma-mapping.h
# (new) -> 1.1 include/asm-ia64/dma-mapping.h
# (new) -> 1.3 include/asm-generic/dma-mapping.h
# (new) -> 1.1 include/asm-alpha/dma-mapping.h
# (new) -> 1.2 include/linux/dma-mapping.h
# (new) -> 1.1 include/asm-ppc/dma-mapping.h
# (new) -> 1.1 include/asm-s390/dma-mapping.h
# (new) -> 1.5 include/asm-i386/dma-mapping.h
# (new) -> 1.1 include/asm-sparc64/dma-mapping.h
# (new) -> 1.1 include/asm-m68k/dma-mapping.h
# (new) -> 1.1 include/asm-mips/dma-mapping.h
# (new) -> 1.1 include/asm-x86_64/dma-mapping.h
# (new) -> 1.1 include/asm-v850/dma-mapping.h
# (new) -> 1.1 include/asm-mips64/dma-mapping.h
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/12/09 jejb@mulgrave.(none) 1.860
# Merge ssh://raven/BK/dma-generic-device-2.5.50
# into mulgrave.(none):/home/jejb/BK/dma-generic-device-2.5
# --------------------------------------------
# 02/12/16 jejb@mulgrave.(none) 1.861
# Documentation complete
# --------------------------------------------
#
diff -Nru a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/Documentation/DMA-API.txt Tue Dec 17 20:49:32 2002
@@ -0,0 +1,325 @@
+ Dynamic DMA mapping using the generic device
+ ============================================
+
+ James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
+
+This document describes the DMA API. For a more gentle introduction
+phrased in terms of the pci_ equivalents (and actual examples) see
+DMA-mapping.txt
+
+This API is split into two pieces. Part I describes the API and the
+corresponding pci_ API. Part II describes the extensions to the API
+for supporting non-consistent memory machines. Unless you know that
+your driver absolutely has to support non-consistent platforms (this
+is usually only legacy platforms) you should only use the API
+described in part I.
+
+Part I - pci_ and dma_ Equivalent API
+-------------------------------------
+
+To get the pci_ API, you must #include <linux/pci.h>
+To get the dma_ API, you must #include <linux/dma-mapping.h>
+
+void *
+dma_alloc_consistent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle)
+void *
+pci_alloc_consistent(struct pci_dev *dev, size_t size,
+ dma_addr_t *dma_handle)
+
+Consistent memory is memory for which a write by either the device or
+the processor can immediately be read by the processor or device
+without having to worry about caching effects.
+
+This routine allocates a region of <size> bytes of consistent memory.
+it also returns a <dma_handle> which may be cast to an unsigned
+integer the same width as the bus and used as the physical address
+base of the region.
+
+Returns: a pointer to the allocated region (in the processor's virtual
+address space) or NULL if the allocation failed.
+
+Note: consistent memory can be expensive on some platforms, and the
+minimum allocation length may be as big as a page, so you should
+consolidate your requests for consistent memory as much as possible.
+
+void
+dma_free_consistent(struct device *dev, size_t size, void *cpu_addr
+ dma_addr_t dma_handle)
+void
+pci_free_consistent(struct pci_dev *dev, size_t size, void *cpu_addr
+ dma_addr_t dma_handle)
+
+Free the region of consistent memory you previously allocated. dev,
+size and dma_handle must all be the same as those passed into the
+consistent allocate. cpu_addr must be the virtual address returned by
+the consistent allocate
+
+int
+dma_supported(struct device *dev, u64 mask)
+int
+pci_dma_supported(struct device *dev, u64 mask)
+
+Checks to see if the device can support DMA to the memory described by
+mask.
+
+Returns: 1 if it can and 0 if it can't.
+
+Notes: This routine merely tests to see if the mask is possible. It
+won't change the current mask settings. It is more intended as an
+internal API for use by the platform than an external API for use by
+driver writers.
+
+int
+dma_set_mask(struct device *dev, u64 mask)
+int
+pci_dma_set_mask(struct pci_device *dev, u64 mask)
+
+Checks to see if the mask is possible and updates the device
+parameters if it is.
+
+Returns: 1 if successful and 0 if not
+
+dma_addr_t
+dma_map_single(struct device *dev, void *cpu_addr, size_t size,
+ enum dma_data_direction direction)
+dma_addr_t
+pci_map_single(struct device *dev, void *cpu_addr, size_t size,
+ int direction)
+
+Maps a piece of processor virtual memory so it can be accessed by the
+device and returns the physical handle of the memory.
+
+The direction for both api's may be converted freely by casting.
+However the dma_ API uses a strongly typed enumerator for its
+direction:
+
+DMA_NONE = PCI_DMA_NONE no direction (used for
+ debugging)
+DMA_TO_DEVICE = PCI_DMA_TODEVICE data is going from the
+ memory to the device
+DMA_FROM_DEVICE = PCI_DMA_FROMDEVICE data is coming from
+ the device to the
+ memory
+DMA_BIDIRECTIONAL = PCI_DMA_BIDIRECTIONAL direction isn't known
+
+Notes: Not all memory regions in a machine can be mapped by this
+API. Further, regions that appear to be physically contiguous in
+kernel virtual space may not be contiguous as physical memory. Since
+this API does not provide any scatter/gather capability, it will fail
+if the user tries to map a non physically contiguous piece of memory.
+For this reason, it is recommended that memory mapped by this API be
+obtained only from sources which guarantee to be physically contiguous
+(like kmalloc).
+
+Further, the physical address of the memory must be within the
+dma_mask of the device (the dma_mask represents a bit mask of the
+addressable region for the device. i.e. if the physical address of
+the memory anded with the dma_mask is still equal to the physical
+address, then the device can perform DMA to the memory). In order to
+ensure that the memory allocated by kmalloc is within the dma_mask,
+the driver may specify various platform dependent flags to restrict
+the physical memory range of the allocation (e.g. on x86, GFP_DMA
+guarantees to be within the first 16Mb of available physical memory,
+as required by ISA devices).
+
+Note also that the above constraints on physical contiguity and
+dma_mask may not apply if the platform has an IOMMU (a device which
+supplies a physical to virtual mapping between the I/O memory bus and
+the device). However, to be portable, device driver writers may *not*
+assume that such an IOMMU exists.
+
+Warnings: Memory coherency operates at a granularity called the cache
+line width. In order for memory mapped by this API to operate
+correctly, the mapped region must begin exactly on a cache line
+boundary and end exactly on one (to prevent two separately mapped
+regions from sharing a single cache line). Since the cache line size
+may not be known at compile time, the API will not enforce this
+requirement. Therefore, it is recommended that driver writers who
+don't take special care to determine the cache line size at run time
+only map virtual regions that begin and end on page boundaries (which
+are guaranteed also to be cache line boundaries).
+
+DMA_TO_DEVICE synchronisation must be done after the last modification
+of the memory region by the software and before it is handed off to
+the driver. Once this primitive is used. Memory covered by this
+primitive should be treated as read only by the device. If the device
+may write to it at any point, it should be DMA_BIDIRECTIONAL (see
+below).
+
+DMA_FROM_DEVICE synchronisation must be done before the driver
+accesses data that may be changed by the device. This memory should
+be treated as read only by the driver. If the driver needs to write
+to it at any point, it should be DMA_BIDIRECTIONAL (see below).
+
+DMA_BIDIRECTIONAL requires special handling: it means that the driver
+isn't sure if the memory was modified before being handed off to the
+device and also isn't sure if the device will also modify it. Thus,
+you must always sync bidirectional memory twice: once before the
+memory is handed off to the device (to make sure all memory changes
+are flushed from the processor) and once before the data may be
+accessed after being used by the device (to make sure any processor
+cache lines are updated with data that the device may have changed.
+
+void
+dma_unmap_single(struct device *dev, dma_addr_t dma_addr, size_t size,
+ enum dma_data_direction direction)
+void
+pci_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_addr,
+ size_t size, int direction)
+
+Unmaps the region previously mapped. All the parameters passed in
+must be identical to those passed in (and returned) by the mapping
+API.
+
+dma_addr_t
+dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction direction)
+dma_addr_t
+pci_map_page(struct pci_dev *hwdev, struct page *page,
+ unsigned long offset, size_t size, int direction)
+void
+dma_unmap_page(struct device *dev, dma_addr_t dma_address, size_t size,
+ enum dma_data_direction direction)
+void
+pci_unmap_page(struct pci_dev *hwdev, dma_addr_t dma_address,
+ size_t size, int direction)
+
+API for mapping and unmapping for pages. All the notes and warnings
+for the other mapping APIs apply here. Also, although the <offset>
+and <size> parameters are provided to do partial page mapping, it is
+recommended that you never use these unless you really know what the
+cache width is.
+
+int
+dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
+ enum dma_data_direction direction)
+int
+pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
+ int nents, int direction)
+
+Maps a scatter gather list from the block layer.
+
+Returns: the number of physical segments mapped (this may be shorted
+than <nents> passed in if the block layer determines that some
+elements of the scatter/gather list are physically adjacent and thus
+may be mapped with a single entry).
+
+void
+dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nhwentries,
+ enum dma_data_direction direction)
+void
+pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg,
+ int nents, int direction)
+
+unmap the previously mapped scatter/gather list. All the parameters
+must be the same as those and passed in to the scatter/gather mapping
+API.
+
+Note: <nents> must be the number you passed in, *not* the number of
+physical entries returned.
+
+void
+dma_sync_single(struct device *dev, dma_addr_t dma_handle, size_t size,
+ enum dma_data_direction direction)
+void
+pci_dma_sync_single(struct pci_dev *hwdev, dma_addr_t dma_handle,
+ size_t size, int direction)
+void
+dma_sync_sg(struct device *dev, struct scatterlist *sg, int nelems,
+ enum dma_data_direction direction)
+void
+pci_dma_sync_sg(struct pci_dev *hwdev, struct scatterlist *sg,
+ int nelems, int direction)
+
+synchronise a single contiguous or scatter/gather mapping. All the
+parameters must be the same as those passed into the single mapping
+API.
+
+Notes: You must do this:
+
+- Before reading values that have been written by DMA from the device
+ (use the DMA_FROM_DEVICE direction)
+- After writing values that will be written to the device using DMA
+ (use the DMA_TO_DEVICE) direction
+- before *and* after handing memory to the device if the memory is
+ DMA_BIDIRECTIONAL
+
+See also dma_map_single().
+
+Part II - Advanced dma_ usage
+-----------------------------
+
+Warning: These pieces of the DMA API have no PCI equivalent. They
+should also not be used in the majority of cases, since they cater for
+unlikely corner cases that don't belong in usual drivers.
+
+If you don't understand how cache line coherency works between a
+processor and an I/O device, you should not be using this part of the
+API at all.
+
+void *
+dma_alloc_nonconsistent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle)
+
+Identical to dma_alloc_consistent() except that the platform will
+choose to return either consistent or non-consistent memory as it sees
+fit. By using this API, you are guaranteeing to the platform that you
+have all the correct and necessary sync points for this memory in the
+driver should it choose to return non-consistent memory.
+
+Note: where the platform can return consistent memory, it will
+guarantee that the sync points become nops.
+
+Warning: Handling non-consistent memory is a real pain. You should
+only ever use this API if you positively know your driver will be
+required to work on one of the rare (usually non-PCI) architectures
+that simply cannot make consistent memory.
+
+void
+dma_free_nonconsistent(struct device *dev, size_t size, void *cpu_addr,
+ dma_addr_t dma_handle)
+
+free memory allocated by the nonconsistent API. All parameters must
+be identical to those passed in (and returned by
+dma_alloc_nonconsistent()).
+
+int
+dma_is_consistent(dma_addr_t dma_handle)
+
+returns true if the memory pointed to by the dma_handle is actually
+consistent.
+
+int
+dma_get_cache_alignment(void)
+
+returns the processor cache alignment. This is the absolute minimum
+alignment *and* width that you must observe when either mapping
+memory or doing partial flushes.
+
+Notes: This API may return a number *larger* than the actual cache
+line, but it will guarantee that one or more cache lines fit exactly
+into the width returned by this call. It will also always be a power
+of two for easy alignment
+
+void
+dma_sync_single_range(struct device *dev, dma_addr_t dma_handle,
+ unsigned long offset, size_t size,
+ enum dma_data_direction direction)
+
+does a partial sync. starting at offset and continuing for size. You
+must be careful to observe the cache alignment and width when doing
+anything like this. You must also be extra careful about accessing
+memory you intend to sync partially.
+
+void
+dma_cache_sync(void *vaddr, size_t size,
+ enum dma_data_direction direction)
+
+Do a partial sync of memory that was allocated by
+dma_alloc_nonconsistent(), starting at virtual address vaddr and
+continuing on for size. Again, you *must* observe the cache line
+boundaries when doing this.
+
+
diff -Nru a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt
--- a/Documentation/DMA-mapping.txt Tue Dec 17 20:49:32 2002
+++ b/Documentation/DMA-mapping.txt Tue Dec 17 20:49:32 2002
@@ -5,6 +5,10 @@
Richard Henderson <rth@cygnus.com>
Jakub Jelinek <jakub@redhat.com>
+This document describes the DMA mapping system in terms of the pci_
+API. For a similar API that works for generic devices, see
+DMA-API.txt.
+
Most of the 64bit platforms have special hardware that translates bus
addresses (DMA addresses) into physical addresses. This is similar to
how page tables and/or a TLB translates virtual addresses to physical
diff -Nru a/arch/i386/kernel/i386_ksyms.c b/arch/i386/kernel/i386_ksyms.c
--- a/arch/i386/kernel/i386_ksyms.c Tue Dec 17 20:49:32 2002
+++ b/arch/i386/kernel/i386_ksyms.c Tue Dec 17 20:49:32 2002
@@ -124,8 +124,8 @@
EXPORT_SYMBOL(__copy_to_user);
EXPORT_SYMBOL(strnlen_user);
-EXPORT_SYMBOL(pci_alloc_consistent);
-EXPORT_SYMBOL(pci_free_consistent);
+EXPORT_SYMBOL(dma_alloc_consistent);
+EXPORT_SYMBOL(dma_free_consistent);
#ifdef CONFIG_PCI
EXPORT_SYMBOL(pcibios_penalize_isa_irq);
diff -Nru a/arch/i386/kernel/pci-dma.c b/arch/i386/kernel/pci-dma.c
--- a/arch/i386/kernel/pci-dma.c Tue Dec 17 20:49:32 2002
+++ b/arch/i386/kernel/pci-dma.c Tue Dec 17 20:49:32 2002
@@ -13,13 +13,13 @@
#include <linux/pci.h>
#include <asm/io.h>
-void *pci_alloc_consistent(struct pci_dev *hwdev, size_t size,
+void *dma_alloc_consistent(struct device *dev, size_t size,
dma_addr_t *dma_handle)
{
void *ret;
int gfp = GFP_ATOMIC;
- if (hwdev == NULL || ((u32)hwdev->dma_mask != 0xffffffff))
+ if (dev == NULL || ((u32)*dev->dma_mask != 0xffffffff))
gfp |= GFP_DMA;
ret = (void *)__get_free_pages(gfp, get_order(size));
@@ -30,7 +30,7 @@
return ret;
}
-void pci_free_consistent(struct pci_dev *hwdev, size_t size,
+void dma_free_consistent(struct device *dev, size_t size,
void *vaddr, dma_addr_t dma_handle)
{
free_pages((unsigned long)vaddr, get_order(size));
diff -Nru a/include/asm-alpha/dma-mapping.h b/include/asm-alpha/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-alpha/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-arm/dma-mapping.h b/include/asm-arm/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-arm/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-cris/dma-mapping.h b/include/asm-cris/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-cris/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-generic/dma-mapping.h b/include/asm-generic/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-generic/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1,154 @@
+/* Copyright (C) 2002 by James.Bottomley@HansenPartnership.com
+ *
+ * Implements the generic device dma API via the existing pci_ one
+ * for unconverted architectures
+ */
+
+#ifndef _ASM_GENERIC_DMA_MAPPING_H
+#define _ASM_GENERIC_DMA_MAPPING_H
+
+/* we implement the API below in terms of the existing PCI one,
+ * so include it */
+#include <linux/pci.h>
+
+static inline int
+dma_supported(struct device *dev, u64 mask)
+{
+ BUG_ON(dev->bus != &pci_bus_type);
+
+ return pci_dma_supported(to_pci_dev(dev), mask);
+}
+
+static inline int
+dma_set_mask(struct device *dev, u64 dma_mask)
+{
+ BUG_ON(dev->bus != &pci_bus_type);
+
+ return pci_set_dma_mask(to_pci_dev(dev), dma_mask);
+}
+
+static inline void *
+dma_alloc_consistent(struct device *dev, size_t size, dma_addr_t *dma_handle)
+{
+ BUG_ON(dev->bus != &pci_bus_type);
+
+ return pci_alloc_consistent(to_pci_dev(dev), size, dma_handle);
+}
+
+static inline void
+dma_free_consistent(struct device *dev, size_t size, void *cpu_addr,
+ dma_addr_t dma_handle)
+{
+ BUG_ON(dev->bus != &pci_bus_type);
+
+ pci_free_consistent(to_pci_dev(dev), size, cpu_addr, dma_handle);
+}
+
+static inline dma_addr_t
+dma_map_single(struct device *dev, void *cpu_addr, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG_ON(dev->bus != &pci_bus_type);
+
+ return pci_map_single(to_pci_dev(dev), cpu_addr, size, (int)direction);
+}
+
+static inline void
+dma_unmap_single(struct device *dev, dma_addr_t dma_addr, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG_ON(dev->bus != &pci_bus_type);
+
+ pci_unmap_single(to_pci_dev(dev), dma_addr, size, (int)direction);
+}
+
+static inline dma_addr_t
+dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG_ON(dev->bus != &pci_bus_type);
+
+ return pci_map_page(to_pci_dev(dev), page, offset, size, (int)direction);
+}
+
+static inline void
+dma_unmap_page(struct device *dev, dma_addr_t dma_address, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG_ON(dev->bus != &pci_bus_type);
+
+ pci_unmap_page(to_pci_dev(dev), dma_address, size, (int)direction);
+}
+
+static inline int
+dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
+ enum dma_data_direction direction)
+{
+ BUG_ON(dev->bus != &pci_bus_type);
+
+ return pci_map_sg(to_pci_dev(dev), sg, nents, (int)direction);
+}
+
+static inline void
+dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nhwentries,
+ enum dma_data_direction direction)
+{
+ BUG_ON(dev->bus != &pci_bus_type);
+
+ pci_unmap_sg(to_pci_dev(dev), sg, nhwentries, (int)direction);
+}
+
+static inline void
+dma_sync_single(struct device *dev, dma_addr_t dma_handle, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG_ON(dev->bus != &pci_bus_type);
+
+ pci_dma_sync_single(to_pci_dev(dev), dma_handle, size, (int)direction);
+}
+
+static inline void
+dma_sync_sg(struct device *dev, struct scatterlist *sg, int nelems,
+ enum dma_data_direction direction)
+{
+ BUG_ON(dev->bus != &pci_bus_type);
+
+ pci_dma_sync_sg(to_pci_dev(dev), sg, nelems, (int)direction);
+}
+
+/* Now for the API extensions over the pci_ one */
+
+#define dma_alloc_nonconsistent(d, s, h) dma_alloc_consistent(d, s, h)
+#define dma_free_nonconsistent(d, s, v, h) dma_free_consistent(d, s, v, h)
+#define dma_is_consistent(d) (1)
+
+static inline int
+dma_get_cache_alignment(void)
+{
+ /* no easy way to get cache size on all processors, so return
+ * the maximum possible, to be safe */
+ return (1 << L1_CACHE_SHIFT_MAX);
+}
+
+static inline void
+dma_sync_single_range(struct device *dev, dma_addr_t dma_handle,
+ unsigned long offset, size_t size,
+ enum dma_data_direction direction)
+{
+ /* just sync everything, that's all the pci API can do */
+ dma_sync_single(dev, dma_handle, offset+size, direction);
+}
+
+static inline void
+dma_cache_sync(void *vaddr, size_t size,
+ enum dma_data_direction direction)
+{
+ /* could define this in terms of the dma_cache ... operations,
+ * but if you get this on a platform, you should convert the platform
+ * to using the generic device DMA API */
+ BUG();
+}
+
+#endif
+
diff -Nru a/include/asm-i386/dma-mapping.h b/include/asm-i386/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-i386/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1,137 @@
+#ifndef _ASM_I386_DMA_MAPPING_H
+#define _ASM_I386_DMA_MAPPING_H
+
+#include <asm/cache.h>
+
+#define dma_alloc_nonconsistent(d, s, h) dma_alloc_consistent(d, s, h)
+#define dma_free_nonconsistent(d, s, v, h) dma_free_consistent(d, s, v, h)
+
+void *dma_alloc_consistent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle);
+
+void dma_free_consistent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_handle);
+
+static inline dma_addr_t
+dma_map_single(struct device *dev, void *ptr, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG_ON(direction == DMA_NONE);
+ flush_write_buffers();
+ return virt_to_phys(ptr);
+}
+
+static inline void
+dma_unmap_single(struct device *dev, dma_addr_t dma_addr, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG_ON(direction == DMA_NONE);
+}
+
+static inline int
+dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
+ enum dma_data_direction direction)
+{
+ int i;
+
+ BUG_ON(direction == DMA_NONE);
+
+ for (i = 0; i < nents; i++ ) {
+ BUG_ON(!sg[i].page);
+
+ sg[i].dma_address = page_to_phys(sg[i].page) + sg[i].offset;
+ }
+
+ flush_write_buffers();
+ return nents;
+}
+
+static inline dma_addr_t
+dma_map_page(struct device *dev, struct page *page, unsigned long offset,
+ size_t size, enum dma_data_direction direction)
+{
+ BUG_ON(direction == DMA_NONE);
+ return (dma_addr_t)(page_to_pfn(page)) * PAGE_SIZE + offset;
+}
+
+static inline void
+dma_unmap_page(struct device *dev, dma_addr_t dma_address, size_t size,
+ enum dma_data_direction direction)
+{
+ BUG_ON(direction == DMA_NONE);
+}
+
+
+static inline void
+dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nhwentries,
+ enum dma_data_direction direction)
+{
+ BUG_ON(direction == DMA_NONE);
+}
+
+static inline void
+dma_sync_single(struct device *dev, dma_addr_t dma_handle, size_t size,
+ enum dma_data_direction direction)
+{
+ flush_write_buffers();
+}
+
+static inline void
+dma_sync_single_range(struct device *dev, dma_addr_t dma_handle,
+ unsigned long offset, size_t size,
+ enum dma_data_direction direction)
+{
+ flush_write_buffers();
+}
+
+
+static inline void
+dma_sync_sg(struct device *dev, struct scatterlist *sg, int nelems,
+ enum dma_data_direction direction)
+{
+ flush_write_buffers();
+}
+
+static inline int
+dma_supported(struct device *dev, u64 mask)
+{
+ /*
+ * we fall back to GFP_DMA when the mask isn't all 1s,
+ * so we can't guarantee allocations that must be
+ * within a tighter range than GFP_DMA..
+ */
+ if(mask < 0x00ffffff)
+ return 0;
+
+ return 1;
+}
+
+static inline int
+dma_set_mask(struct device *dev, u64 mask)
+{
+ if(!dev->dma_mask || !dma_supported(dev, mask))
+ return -EIO;
+
+ *dev->dma_mask = mask;
+
+ return 0;
+}
+
+static inline int
+dma_get_cache_alignment(void)
+{
+ /* no easy way to get cache size on all x86, so return the
+ * maximum possible, to be safe */
+ return (1 << L1_CACHE_SHIFT_MAX);
+}
+
+#define dma_is_consistent(d) (1)
+
+static inline void
+dma_cache_sync(void *vaddr, size_t size,
+ enum dma_data_direction direction)
+{
+ flush_write_buffers();
+}
+
+#endif
diff -Nru a/include/asm-i386/pci.h b/include/asm-i386/pci.h
--- a/include/asm-i386/pci.h Tue Dec 17 20:49:32 2002
+++ b/include/asm-i386/pci.h Tue Dec 17 20:49:32 2002
@@ -6,6 +6,9 @@
#ifdef __KERNEL__
#include <linux/mm.h> /* for struct page */
+/* we support the new DMA API, but still provide the old one */
+#define PCI_NEW_DMA_COMPAT_API 1
+
/* Can be used to override the logic in pci_scan_bus for skipping
already-configured bus numbers - to be used for buggy BIOSes
or architectures with incomplete PCI setup by the loader */
@@ -46,78 +49,6 @@
*/
#define PCI_DMA_BUS_IS_PHYS (1)
-/* Allocate and map kernel buffer using consistent mode DMA for a device.
- * hwdev should be valid struct pci_dev pointer for PCI devices,
- * NULL for PCI-like buses (ISA, EISA).
- * Returns non-NULL cpu-view pointer to the buffer if successful and
- * sets *dma_addrp to the pci side dma address as well, else *dma_addrp
- * is undefined.
- */
-extern void *pci_alloc_consistent(struct pci_dev *hwdev, size_t size,
- dma_addr_t *dma_handle);
-
-/* Free and unmap a consistent DMA buffer.
- * cpu_addr is what was returned from pci_alloc_consistent,
- * size must be the same as what as passed into pci_alloc_consistent,
- * and likewise dma_addr must be the same as what *dma_addrp was set to.
- *
- * References to the memory and mappings associated with cpu_addr/dma_addr
- * past this call are illegal.
- */
-extern void pci_free_consistent(struct pci_dev *hwdev, size_t size,
- void *vaddr, dma_addr_t dma_handle);
-
-/* Map a single buffer of the indicated size for DMA in streaming mode.
- * The 32-bit bus address to use is returned.
- *
- * Once the device is given the dma address, the device owns this memory
- * until either pci_unmap_single or pci_dma_sync_single is performed.
- */
-static inline dma_addr_t pci_map_single(struct pci_dev *hwdev, void *ptr,
- size_t size, int direction)
-{
- if (direction == PCI_DMA_NONE)
- BUG();
- flush_write_buffers();
- return virt_to_phys(ptr);
-}
-
-/* Unmap a single streaming mode DMA translation. The dma_addr and size
- * must match what was provided for in a previous pci_map_single call. All
- * other usages are undefined.
- *
- * After this call, reads by the cpu to the buffer are guarenteed to see
- * whatever the device wrote there.
- */
-static inline void pci_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_addr,
- size_t size, int direction)
-{
- if (direction == PCI_DMA_NONE)
- BUG();
- /* Nothing to do */
-}
-
-/*
- * pci_{map,unmap}_single_page maps a kernel page to a dma_addr_t. identical
- * to pci_map_single, but takes a struct page instead of a virtual address
- */
-static inline dma_addr_t pci_map_page(struct pci_dev *hwdev, struct page *page,
- unsigned long offset, size_t size, int direction)
-{
- if (direction == PCI_DMA_NONE)
- BUG();
-
- return (dma_addr_t)(page_to_pfn(page)) * PAGE_SIZE + offset;
-}
-
-static inline void pci_unmap_page(struct pci_dev *hwdev, dma_addr_t dma_address,
- size_t size, int direction)
-{
- if (direction == PCI_DMA_NONE)
- BUG();
- /* Nothing to do */
-}
-
/* pci_unmap_{page,single} is a nop so... */
#define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME)
#define DECLARE_PCI_UNMAP_LEN(LEN_NAME)
@@ -126,84 +57,6 @@
#define pci_unmap_len(PTR, LEN_NAME) (0)
#define pci_unmap_len_set(PTR, LEN_NAME, VAL) do { } while (0)
-/* Map a set of buffers described by scatterlist in streaming
- * mode for DMA. This is the scather-gather version of the
- * above pci_map_single interface. Here the scatter gather list
- * elements are each tagged with the appropriate dma address
- * and length. They are obtained via sg_dma_{address,length}(SG).
- *
- * NOTE: An implementation may be able to use a smaller number of
- * DMA address/length pairs than there are SG table elements.
- * (for example via virtual mapping capabilities)
- * The routine returns the number of addr/length pairs actually
- * used, at most nents.
- *
- * Device ownership issues as mentioned above for pci_map_single are
- * the same here.
- */
-static inline int pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
- int nents, int direction)
-{
- int i;
-
- if (direction == PCI_DMA_NONE)
- BUG();
-
- for (i = 0; i < nents; i++ ) {
- if (!sg[i].page)
- BUG();
-
- sg[i].dma_address = page_to_phys(sg[i].page) + sg[i].offset;
- }
-
- flush_write_buffers();
- return nents;
-}
-
-/* Unmap a set of streaming mode DMA translations.
- * Again, cpu read rules concerning calls here are the same as for
- * pci_unmap_single() above.
- */
-static inline void pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg,
- int nents, int direction)
-{
- if (direction == PCI_DMA_NONE)
- BUG();
- /* Nothing to do */
-}
-
-/* Make physical memory consistent for a single
- * streaming mode DMA translation after a transfer.
- *
- * If you perform a pci_map_single() but wish to interrogate the
- * buffer using the cpu, yet do not wish to teardown the PCI dma
- * mapping, you must call this function before doing so. At the
- * next point you give the PCI dma address back to the card, the
- * device again owns the buffer.
- */
-static inline void pci_dma_sync_single(struct pci_dev *hwdev,
- dma_addr_t dma_handle,
- size_t size, int direction)
-{
- if (direction == PCI_DMA_NONE)
- BUG();
- flush_write_buffers();
-}
-
-/* Make physical memory consistent for a set of streaming
- * mode DMA translations after a transfer.
- *
- * The same as pci_dma_sync_single but for a scatter-gather list,
- * same rules and usage.
- */
-static inline void pci_dma_sync_sg(struct pci_dev *hwdev,
- struct scatterlist *sg,
- int nelems, int direction)
-{
- if (direction == PCI_DMA_NONE)
- BUG();
- flush_write_buffers();
-}
/* Return whether the given PCI device DMA address mask can
* be supported properly. For example, if your device can
diff -Nru a/include/asm-ia64/dma-mapping.h b/include/asm-ia64/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-ia64/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-m68k/dma-mapping.h b/include/asm-m68k/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-m68k/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-m68knommu/dma-mapping.h b/include/asm-m68knommu/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-m68knommu/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-mips/dma-mapping.h b/include/asm-mips/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-mips/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-mips64/dma-mapping.h b/include/asm-mips64/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-mips64/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-ppc/dma-mapping.h b/include/asm-ppc/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-ppc/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-ppc64/dma-mapping.h b/include/asm-ppc64/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-ppc64/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-s390/dma-mapping.h b/include/asm-s390/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-s390/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-s390x/dma-mapping.h b/include/asm-s390x/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-s390x/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-sh/dma-mapping.h b/include/asm-sh/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-sh/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-sparc/dma-mapping.h b/include/asm-sparc/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-sparc/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-sparc64/dma-mapping.h b/include/asm-sparc64/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-sparc64/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-um/dma-mapping.h b/include/asm-um/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-um/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-v850/dma-mapping.h b/include/asm-v850/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-v850/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/asm-x86_64/dma-mapping.h b/include/asm-x86_64/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/asm-x86_64/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1 @@
+#include <asm-generic/dma-mapping.h>
diff -Nru a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
--- /dev/null Wed Dec 31 16:00:00 1969
+++ b/include/linux/dma-mapping.h Tue Dec 17 20:49:32 2002
@@ -0,0 +1,17 @@
+#ifndef _ASM_LINUX_DMA_MAPPING_H
+#define _ASM_LINUX_DMA_MAPPING_H
+
+/* These definitions mirror those in pci.h, so they can be used
+ * interchangeably with their PCI_ counterparts */
+enum dma_data_direction {
+ DMA_BIDIRECTIONAL = 0,
+ DMA_TO_DEVICE = 1,
+ DMA_FROM_DEVICE = 2,
+ DMA_NONE = 3,
+};
+
+#include <asm/dma-mapping.h>
+
+#endif
+
+
diff -Nru a/include/linux/pci.h b/include/linux/pci.h
--- a/include/linux/pci.h Tue Dec 17 20:49:32 2002
+++ b/include/linux/pci.h Tue Dec 17 20:49:32 2002
@@ -826,5 +826,92 @@
#define PCIPCI_VIAETBF 8
#define PCIPCI_VSFX 16
+#include <linux/dma-mapping.h>
+
+/* If you define PCI_NEW_DMA_COMPAT_API it means you support the new DMA API
+ * and you want the pci_ DMA API to be implemented using it.
+ */
+#if defined(PCI_NEW_DMA_COMPAT_API) && defined(CONFIG_PCI)
+
+/* note pci_set_dma_mask isn't here, since it's a public function
+ * exported from drivers/pci, use dma_supported instead */
+
+static inline int
+pci_dma_supported(struct pci_dev *hwdev, u64 mask)
+{
+ return dma_supported(&hwdev->dev, mask);
+}
+
+static inline void *
+pci_alloc_consistent(struct pci_dev *hwdev, size_t size,
+ dma_addr_t *dma_handle)
+{
+ return dma_alloc_consistent(&hwdev->dev, size, dma_handle);
+}
+
+static inline void
+pci_free_consistent(struct pci_dev *hwdev, size_t size,
+ void *vaddr, dma_addr_t dma_handle)
+{
+ dma_free_consistent(&hwdev->dev, size, vaddr, dma_handle);
+}
+
+static inline dma_addr_t
+pci_map_single(struct pci_dev *hwdev, void *ptr, size_t size, int direction)
+{
+ return dma_map_single(&hwdev->dev, ptr, size, (enum dma_data_direction)direction);
+}
+
+static inline void
+pci_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_addr,
+ size_t size, int direction)
+{
+ dma_unmap_single(&hwdev->dev, dma_addr, size, (enum dma_data_direction)direction);
+}
+
+static inline dma_addr_t
+pci_map_page(struct pci_dev *hwdev, struct page *page,
+ unsigned long offset, size_t size, int direction)
+{
+ return dma_map_page(&hwdev->dev, page, offset, size, (enum dma_data_direction)direction);
+}
+
+static inline void
+pci_unmap_page(struct pci_dev *hwdev, dma_addr_t dma_address,
+ size_t size, int direction)
+{
+ dma_unmap_page(&hwdev->dev, dma_address, size, (enum dma_data_direction)direction);
+}
+
+static inline int
+pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,
+ int nents, int direction)
+{
+ return dma_map_sg(&hwdev->dev, sg, nents, (enum dma_data_direction)direction);
+}
+
+static inline void
+pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg,
+ int nents, int direction)
+{
+ dma_unmap_sg(&hwdev->dev, sg, nents, (enum dma_data_direction)direction);
+}
+
+static inline void
+pci_dma_sync_single(struct pci_dev *hwdev, dma_addr_t dma_handle,
+ size_t size, int direction)
+{
+ dma_sync_single(&hwdev->dev, dma_handle, size, (enum dma_data_direction)direction);
+}
+
+static inline void
+pci_dma_sync_sg(struct pci_dev *hwdev, struct scatterlist *sg,
+ int nelems, int direction)
+{
+ dma_sync_sg(&hwdev->dev, sg, nelems, (enum dma_data_direction)direction);
+}
+
+#endif
+
#endif /* __KERNEL__ */
#endif /* LINUX_PCI_H */
^ permalink raw reply
* netfilter wont forget old rule
From: Henrik Gram @ 2002-12-18 2:50 UTC (permalink / raw)
To: netfilter-devel
I have a rule like this:
iptables -t nat -A PREROUTING -i ! eth0 -p udp --dport 500 -j DNAT --to a.b.c.d
Which worked fine sending isakmp messages coming in from our two ISP's
(eth1 and eth2) to our VPN gateway. However, I was wanting to make another
machine the VPN gateway and changed the above line with the updated
ip. The list of rules was flushed first and in the iptables -L, only the
new rule shows up. However, tcpdump reveals that the box is still
forwarding those packets to the old address. I cannot figure out why.. I
tried adding a LOG target as the first rule but that wasn't matched
either. For some reason it keeps insisting on using the old rule which is
not listed anywhere.
The box is running 2.4.19-rc1 and iptables v1.2.6a.
--
Henrik Gram
^ permalink raw reply
* New selinux-small with automake?
From: Joshua Brindle @ 2002-12-18 2:44 UTC (permalink / raw)
To: selinux
[-- Attachment #1: Type: text/plain, Size: 138 bytes --]
Any chance of the new selinux-small package with automake being posted?
Joshua Brindle
UNIX Administrator
Southern Nazarene University
[-- Attachment #2: HTML --]
[-- Type: text/html, Size: 513 bytes --]
^ permalink raw reply
* Re: Announce: XFS split patches for 2.4.20 - respin
From: khromy @ 2002-12-18 3:04 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <6153.1040177760@kao2.melbourne.sgi.com>
What are the chances of this getting into 2.4 soon?
On Wed, Dec 18, 2002 at 01:16:00PM +1100, Keith Owens wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Content-Type: text/plain; charset=us-ascii
>
> ftp://oss.sgi.com/projects/xfs/download/patches/2.4.20.
>
> The xfs patches for 2.4.20 have been respun as of 2002-12-18 02:00 UTC.
>
> For some time the XFS group have been producing split patches for XFS,
> separating the core XFS changes from additional patches such as kdb,
> xattr, acl, dmapi. The split patches are released to the world with
> the hope that developers and distributors will find them useful.
>
> Read the README in each directory very carefully, the split patch
> format has changed over a few kernel releases. Any questions that are
> covered by the README will be ignored. There is even a 2.4.21/README
> for the terminally impatient :).
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: Exmh version 2.1.1 10/15/1999
>
> iD8DBQE9/9pdi4UHNye0ZOoRAjd7AKCUGoWqZ3SJGRj2d7ssCEsiZb03vwCdFm4J
> 5ymEscu9jY2EEZuwz2NwPK0=
> =0KMC
> -----END PGP SIGNATURE-----
--
L1: khromy ;khromy(at)lnuxlab.ath.cx
^ permalink raw reply
* Arctic-2 touchscreen driver
From: David Gibson @ 2002-12-18 2:35 UTC (permalink / raw)
To: linuxppc-embedded
Below is a patch against linuxppc_2_4_devel which adds support for the
touchscreen controller on the Arctic-2: this is a Semtech device
attached to the 405LP's second serial port.
This driver is *not* ready to be committed to the tree - if nothing
else, it arbitrarily allocates a new constant in
include/linux/serio.h. Still, I'm sending this patch out so people
can look at it, and so the (very few, so far) people outside IBM with
Arctic-2s can start to play with it.
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/drivers/char/Config.in linux-bartholomew/drivers/char/Config.in
--- /home/dgibson/kernel/linuxppc_2_4_devel/drivers/char/Config.in 2002-12-16 15:09:46.000000000 +1100
+++ linux-bartholomew/drivers/char/Config.in 2002-12-17 16:24:31.000000000 +1100
@@ -361,4 +361,9 @@
tristate 'Xilinx on-chip GPIO' CONFIG_XILINX_GPIO
fi
+# FIXME: depend on SERIO/SERPORT too?
+if [ "$CONFIG_ARCTIC2" = "y" ]; then
+ tristate 'Arctic II Semtech Touchscreen controller' CONFIG_IBMTS_SEMTECH
+fi
+
endmenu
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/drivers/char/Makefile linux-bartholomew/drivers/char/Makefile
--- /home/dgibson/kernel/linuxppc_2_4_devel/drivers/char/Makefile 2002-12-16 15:09:46.000000000 +1100
+++ linux-bartholomew/drivers/char/Makefile 2002-12-17 16:24:59.000000000 +1100
@@ -290,6 +290,7 @@
obj-$(CONFIG_AMD7XX_TCO) += amd7xx_tco.o
obj-$(CONFIG_PPC405_WDT) += ppc405_wdt.o
obj-$(CONFIG_IBM_OCP_GPIO) += ibm_ocp_gpio.o
+obj-$(CONFIG_IBMTS_SEMTECH) += ibmts_semtech.o
mod-subdirs += xilinx_gpio
subdir-$(CONFIG_XILINX_GPIO) += xilinx_gpio
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/drivers/char/ibmts_semtech.c linux-bartholomew/drivers/char/ibmts_semtech.c
--- /home/dgibson/kernel/linuxppc_2_4_devel/drivers/char/ibmts_semtech.c Thu Jan 01 10:00:00 1970
+++ linux-bartholomew/drivers/char/ibmts_semtech.c Wed Dec 18 13:32:31 2002
@@ -0,0 +1,380 @@
+/* IBM Arctic-2 Semtech touch panel controller driver for /dev/ibmts interface
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Copyright (C) 2002 IBM Corporation.
+ *
+ * Ken Inoue
+ * IBM Thomas J. Watson Research Center
+ * <keninoue@us.ibm.com>
+ *
+ * David Gibson
+ * IBM OzLabs, Canberra, Australia.
+ * <arctic@gibson.dropbear.id.au>
+ */
+
+#include <linux/module.h> /* Get my module mojo */
+#include <linux/types.h> /* int16_t ... */
+#include <linux/poll.h> /* polling macros */
+#include <linux/interrupt.h> /* Tasklets */
+#include <linux/sched.h> /* wait_on, etc */
+#include <linux/wait.h> /* wait queues */
+#include <linux/init.h> /* module_init() macro */
+#include <linux/spinlock.h> /* mutex structures/code */
+#include <linux/fs.h> /* struct file, struct inode */
+#include <linux/serio.h>
+
+#define IBMTS_DEVICE_NAME "ibmts"
+#define IBMTS_MAJOR 254
+
+#define IBMTS_SAMPLES 128
+#define IBMTS_TIMEOUT_INTERVAL 10
+
+#define PEN_RELEASE 0
+#define PEN_GLIDE 2
+#define PEN_PRESS 1
+
+struct ts_event {
+ short pressure; /* Pressure of stylus - 0 for release, positive otherwise */
+ int x; /* X coordinate stylus - -1 for PEN_RELEASE */
+ int y; /* Y coordinate stylus - -1 for PEN_RELEASE */
+ int millisecs; /* A timestamp */
+ unsigned int flags; /* kind of event, and reserved bits */
+};
+
+typedef struct ibmts_semtech_event {
+ struct ibmts_semtech_event *pNext;
+ struct ts_event event;
+} ibmts_semtech_event;
+
+// HACK: FIXME: put the following in a dynamically allocated struct
+
+static int IsOpenForRead = 0;
+
+static unsigned char pen_down = 0;
+
+static wait_queue_head_t ibmts_semtech_proc_list;
+
+static spinlock_t ibmts_semtech_lock = SPIN_LOCK_UNLOCKED;
+
+#define SEMTECH_FSM_RESET 0
+#define SEMTECH_FSM_DATA_READY 4
+
+#define SEMTECH_SYNC_FLAG 0x80
+
+static unsigned char semtech_FSM = SEMTECH_FSM_RESET;
+static unsigned char semtech_data_index = 0;
+static unsigned char semtech_data[4];
+static unsigned char semtech_FSM_next[] = {
+ (SEMTECH_FSM_RESET + 1), (SEMTECH_FSM_RESET + 2),
+ (SEMTECH_FSM_RESET + 3), SEMTECH_FSM_DATA_READY
+};
+
+static ibmts_semtech_event events[IBMTS_SAMPLES];
+
+static ibmts_semtech_event *ibmts_semtech_rdp = NULL;
+static ibmts_semtech_event *ibmts_semtech_wrp = NULL;
+
+static int queue_empty(void)
+{
+ return (ibmts_semtech_rdp == ibmts_semtech_wrp);
+}
+
+struct ts_event *ibmts_semtech_get_event(void)
+{
+ unsigned long flags;
+ ibmts_semtech_event *result;
+
+ spin_lock_irqsave(&ibmts_semtech_lock, flags);
+
+ if ( (ibmts_semtech_rdp == NULL) || queue_empty() )
+ return NULL;
+
+ result = ibmts_semtech_rdp;
+ ibmts_semtech_rdp = ibmts_semtech_rdp->pNext;
+
+ spin_unlock_irqrestore(&ibmts_semtech_lock, flags);
+ return &(result->event);
+};
+
+static void ibmts_semtech_put_event(struct ts_event *pEvent)
+{
+ if ( ibmts_semtech_rdp == NULL)
+ return;
+
+ if (! IsOpenForRead)
+ return;
+
+ ibmts_semtech_wrp->event.pressure = pEvent->pressure;
+ ibmts_semtech_wrp->event.x = pEvent->x;
+ ibmts_semtech_wrp->event.y = pEvent->y;
+ ibmts_semtech_wrp->event.millisecs = pEvent->millisecs;
+ ibmts_semtech_wrp->event.flags = pEvent->flags;
+
+ ibmts_semtech_wrp = ibmts_semtech_wrp->pNext;
+ if (ibmts_semtech_wrp == ibmts_semtech_rdp) /* Wrap */
+ ibmts_semtech_rdp = ibmts_semtech_rdp->pNext; /* Write over */
+ else
+ if (waitqueue_active(&ibmts_semtech_proc_list))
+ wake_up_interruptible(&ibmts_semtech_proc_list);
+}
+
+static int ibmts_semtech_open(struct inode *inode, struct file *file)
+{
+ int i;
+
+ printk("ibmts: %d.%d\n",
+ inode->i_rdev >> 8, inode->i_rdev & 0xFF);
+ if (file->f_flags & O_NONBLOCK)
+ printk("ibmts: Non-blocked mode\n");
+ else
+ printk("ibmts: Blocked mode\n");
+
+ if ((file-> f_mode & FMODE_READ)) {
+ if (IsOpenForRead)
+ return -EBUSY;
+ IsOpenForRead++;
+ }
+
+
+ /* Initialize the structs. */
+ ibmts_semtech_rdp = &(events[0]);
+ ibmts_semtech_wrp = ibmts_semtech_rdp;
+ for (i=0; i<IBMTS_SAMPLES; i++)
+ events[i].pNext = &(events[i+1]);
+
+ events[IBMTS_SAMPLES-1].pNext = &(events[0]);
+ pen_down = 0;
+ semtech_FSM = SEMTECH_FSM_RESET;
+ semtech_data_index = 0;
+
+ MOD_INC_USE_COUNT;
+
+ return 0;
+}
+
+
+static int ibmts_semtech_release(struct inode *inode, struct file *file)
+{
+ if ((file-> f_mode & FMODE_READ))
+ IsOpenForRead--;
+
+ MOD_DEC_USE_COUNT;
+
+ return 0;
+}
+
+static ssize_t ibmts_semtech_read(struct file *pFile, char *buffer,
+ size_t count, loff_t *ppos)
+{
+ ssize_t bytes_read = 0;
+ struct ts_event *pWork;
+
+ while (queue_empty()) { /* wait for an event */
+ if (pFile->f_flags & O_NONBLOCK)
+ return -EWOULDBLOCK;
+
+ if (wait_event_interruptible(ibmts_semtech_proc_list, ! queue_empty()))
+ return -ERESTARTSYS;
+ }
+
+ while ( (bytes_read < count) && (! queue_empty()) ) {
+ pWork = ibmts_semtech_get_event();
+ if (pWork) {
+ if (copy_to_user (buffer + bytes_read, (void *) pWork,
+ sizeof(struct ts_event))) {
+ bytes_read = -EFAULT;
+ break;
+ }
+ bytes_read += sizeof(struct ts_event);
+ if (count - bytes_read < sizeof(struct ts_event)) break;
+ }
+ }
+
+ if (bytes_read > 0)
+ return bytes_read;
+
+ if (signal_pending(current))
+ return -ERESTARTSYS;
+
+ return bytes_read;
+}
+
+static ssize_t ibmts_semtech_write(struct file *file, const char *buffer,
+ size_t length, loff_t *ppos)
+{
+ return -EINVAL;
+}
+
+static int ibmts_semtech_ioctl(struct inode * dev_inode, struct file *filep,
+ unsigned int cmd, unsigned long arg)
+{
+ return -EINVAL;
+}
+
+/*
+ Poll for input - return code indicating if there is input to read.
+ */
+
+static unsigned int
+ibmts_semtech_poll (struct file* filp, poll_table * wait)
+{
+ poll_wait(filp, &ibmts_semtech_proc_list, wait);
+ return queue_empty() ? 0 : (POLLIN | POLLRDNORM);
+}
+
+/* Module Declarations ***************************** */
+
+static struct file_operations ibmts_semtech_fops = {
+ .owner = THIS_MODULE,
+ .open = ibmts_semtech_open,
+ .read = ibmts_semtech_read,
+ .write = ibmts_semtech_write,
+ .ioctl = ibmts_semtech_ioctl,
+ .poll = ibmts_semtech_poll,
+ .release = ibmts_semtech_release
+};
+
+/*
+ * Serial I/O routines (requires drivers/char/joystick/serio and serport)
+ */
+
+static void semtech_parse_data(unsigned char *pData)
+{
+ struct ts_event event;
+ unsigned int dx, dy;
+
+/* #define IBMTS_SEMTECH_XYSWAP */
+
+#if defined(IBMTS_SEMTECH_XYSWAP)
+ dx = (((unsigned int)pData[1] & 0x70) << 3) | ((unsigned int)pData[3] & 0x7f);
+ dy = (((unsigned int)pData[1] & 0x07) << 7) | ((unsigned int)pData[2] & 0x7f);
+#else
+ dy = (((unsigned int)pData[1] & 0x70) << 3) | ((unsigned int)pData[3] & 0x7f);
+ dx = (((unsigned int)pData[1] & 0x07) << 7) | ((unsigned int)pData[2] & 0x7f);
+#endif
+
+ if (! pen_down) { /* Pen up until now */
+ if (( pData[0] & 0x1f)) { /* Pen still up */
+ return;
+ } else {
+ event.flags = PEN_PRESS; /* Press */
+ event.x = dx;
+ event.y = dy;
+ event.pressure = 500;
+ event.millisecs = jiffies*10;
+ pen_down = 1;
+ }
+
+ } else { /* Pen was down */
+ if (pData[0] & 0x07f) { /* Pen up */
+ event.flags = PEN_RELEASE; /* 0: Up */
+ event.x = -1;
+ event.y = -1;
+ event.pressure = 0;
+ event.millisecs = jiffies*10;
+ pen_down = 0;
+ } else {
+ event.flags = PEN_GLIDE;
+ event.x = dx;
+ event.y = dy;
+ event.pressure = 500;
+ event.millisecs = jiffies * 10;
+ }
+ }
+ ibmts_semtech_put_event(&event); /* Wakeup handled in put_event() */
+}
+
+static void semtechts_interrupt(struct serio *serio, unsigned char data, unsigned int flags)
+{
+ /* Between packets & sync flag on, or In packet & sync flag off */
+ if ( ( (semtech_FSM == SEMTECH_FSM_RESET) && (data & SEMTECH_SYNC_FLAG) ) ||
+ ( (semtech_FSM != SEMTECH_FSM_RESET) && !(data & SEMTECH_SYNC_FLAG) ) ) {
+ /* Record and proceed to next stage */
+ semtech_data[semtech_data_index++] = data;
+ semtech_FSM = semtech_FSM_next[semtech_FSM];
+ } else { /* Out of sync */
+ semtech_FSM = SEMTECH_FSM_RESET;
+ }
+
+ /* Full packet received, process it now */
+ if (semtech_FSM == SEMTECH_FSM_DATA_READY) {
+ semtech_parse_data(semtech_data);
+ semtech_FSM = SEMTECH_FSM_RESET;
+ semtech_data_index = 0;
+ }
+
+}
+
+static void semtechts_connect(struct serio *serio, struct serio_dev *dev)
+{
+ if (serio->type != (SERIO_RS232 | SERIO_SEMTECHTS)) { /* Must be in serio.h and inputattach.c */
+ printk("semtechts_connect(): serio has wrong type\n");
+ return;
+ }
+
+ if (serio_open(serio, dev)) {
+ printk("semtechts: serio_open failed\n");
+ return;
+ }
+}
+
+static void semtechts_disconnect(struct serio *serio)
+{
+ serio_close(serio);
+}
+
+static struct serio_dev semtechts_dev = {
+ .interrupt = semtechts_interrupt,
+ .connect = semtechts_connect,
+ .disconnect = semtechts_disconnect,
+};
+
+MODULE_AUTHOR("Ken Inoue");
+MODULE_DESCRIPTION("IBM Arctic-2 Semtech touch panel controller driver\n");
+
+int __init init_ibmts_semtech_module(void)
+{
+ int err;
+
+ init_waitqueue_head(&ibmts_semtech_proc_list);
+
+ err = register_chrdev(IBMTS_MAJOR, IBMTS_DEVICE_NAME, &ibmts_semtech_fops);
+
+ if (err < 0) {
+ printk("ibmts_semtech: register_chrdev failed with %d\n", err);
+ return err;
+ }
+
+ printk("ibmts_semtech: v0.02 e-8 device major %d \n", IBMTS_MAJOR);
+
+ serio_register_device(&semtechts_dev);
+
+ return 0;
+}
+
+void cleanup_ibmts_semtech_module(void)
+{
+ int ret;
+
+ ret = unregister_chrdev(IBMTS_MAJOR, IBMTS_DEVICE_NAME);
+ if (ret < 0)
+ printk("Error : unregister_chrdev: %d\n", ret);
+
+ serio_unregister_device(&semtechts_dev);
+}
+
+module_init(init_ibmts_semtech_module);
+module_exit(cleanup_ibmts_semtech_module);
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [announce] procps 2.0.11
From: Robert Love @ 2002-12-18 2:36 UTC (permalink / raw)
To: Andreas Steinmetz; +Cc: Andrei Ivanov, procps-list, linux-kernel, riel
In-Reply-To: <3DFFCF12.6050902@domdv.de>
On Tue, 2002-12-17 at 20:27, Andreas Steinmetz wrote:
> The attached patch does fix this.
Indeed, this is correct - thanks.
I committed the patch to CVS.
Robert Love
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.