* [PATCH 059/199] Documentation/isdn/README.pcbit: Checkpatch cleanup
From: Andrea Gelmini @ 2010-05-23 19:50 UTC (permalink / raw)
To: andrea.gelmini; +Cc: Karsten Keil, Randy Dunlap, netdev, linux-doc
In-Reply-To: <1274644226-23612-1-git-send-email-andrea.gelmini@gelma.net>
Documentation/isdn/README.pcbit:10: ERROR: trailing whitespace
Documentation/isdn/README.pcbit:39: ERROR: trailing whitespace
Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
---
Documentation/isdn/README.pcbit | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/isdn/README.pcbit b/Documentation/isdn/README.pcbit
index 5125002..6fe8f08 100644
--- a/Documentation/isdn/README.pcbit
+++ b/Documentation/isdn/README.pcbit
@@ -7,7 +7,7 @@ developed in cooperation with Portugal Telecom and Inesc.
The driver interfaces with the standard kernel isdn facilities
originally developed by Fritz Elfert in the isdn4linux project.
-The common versions of the pcbit board require a firmware that is
+The common versions of the pcbit board require a firmware that is
distributed (and copyrighted) by the manufacturer. To load this
firmware you need "pcbitctl" available on the standard isdn4k-utils
package or in the pcbit package available in:
@@ -36,5 +36,5 @@ mailing list (isdn4linux@listserv.isdn4linux.de) or directly from me.
regards,
Pedro.
-
+
<roque@di.fc.ul.pt>
--
1.7.1.251.gf80a2
^ permalink raw reply related
* [PATCH 058/199] Documentation/isdn/README.hfc-pci: Checkpatch cleanup
From: Andrea Gelmini @ 2010-05-23 19:50 UTC (permalink / raw)
To: andrea.gelmini; +Cc: Karsten Keil, Randy Dunlap, netdev, linux-doc
In-Reply-To: <1274644226-23612-1-git-send-email-andrea.gelmini@gelma.net>
Documentation/isdn/README.hfc-pci:19: ERROR: trailing whitespace
Documentation/isdn/README.hfc-pci:25: ERROR: trailing whitespace
Documentation/isdn/README.hfc-pci:27: ERROR: trailing whitespace
Documentation/isdn/README.hfc-pci:32: ERROR: trailing whitespace
Documentation/isdn/README.hfc-pci:34: ERROR: trailing whitespace
Documentation/isdn/README.hfc-pci:36: ERROR: trailing whitespace
Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
---
Documentation/isdn/README.hfc-pci | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/isdn/README.hfc-pci b/Documentation/isdn/README.hfc-pci
index e8a4ef0..a61227f 100644
--- a/Documentation/isdn/README.hfc-pci
+++ b/Documentation/isdn/README.hfc-pci
@@ -16,24 +16,24 @@ And then:
hisaxctrl <driver/cardname> 12 1
-This enables the echo mode. If Hex logging is activated the isdnctrlx
+This enables the echo mode. If Hex logging is activated the isdnctrlx
devices show a output with a line beginning of HEX: for the providers
exchange and ECHO: for isdn devices sending to the provider.
If more than one HFC-PCI cards are installed, a specific card may be selected
at the hisax module load command line. Supply the load command with the desired
-IO-address of the desired card.
+IO-address of the desired card.
Example:
-There tree cards installed in your machine at IO-base addresses 0xd000, 0xd400
+There tree cards installed in your machine at IO-base addresses 0xd000, 0xd400
and 0xdc00
If you want to use the card at 0xd400 standalone you should supply the insmod
or depmod with type=35 io=0xd400.
If you want to use all three cards, but the order needs to be at 0xdc00,0xd400,
-0xd000 you may give the parameters type=35,35,35 io=0xdc00,0xd400,0xd00
+0xd000 you may give the parameters type=35,35,35 io=0xdc00,0xd400,0xd00
Then the desired card will be the initialised in the desired order.
-If the io parameter is used the io addresses of all used cards should be
+If the io parameter is used the io addresses of all used cards should be
supplied else the parameter is assumed 0 and a auto search for a free card is
-invoked which may not give the wanted result.
+invoked which may not give the wanted result.
Comments and reports to werner@isdn4linux.de or werner@isdn-development.de
--
1.7.1.251.gf80a2
^ permalink raw reply related
* [PATCH 053/199] Documentation/isdn/README.HiSax: Checkpatch cleanup
From: Andrea Gelmini @ 2010-05-23 19:50 UTC (permalink / raw)
To: andrea.gelmini; +Cc: Karsten Keil, Randy Dunlap, netdev, linux-doc
In-Reply-To: <1274644226-23612-1-git-send-email-andrea.gelmini@gelma.net>
Documentation/isdn/README.HiSax:62: ERROR: trailing whitespace
Documentation/isdn/README.HiSax:191: ERROR: trailing whitespace
Documentation/isdn/README.HiSax:192: ERROR: trailing whitespace
Documentation/isdn/README.HiSax:200: ERROR: trailing whitespace
Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
---
Documentation/isdn/README.HiSax | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/isdn/README.HiSax b/Documentation/isdn/README.HiSax
index 031c8d8..de8a9fc 100644
--- a/Documentation/isdn/README.HiSax
+++ b/Documentation/isdn/README.HiSax
@@ -59,7 +59,7 @@ Traverse Technologie NETjet PCI S0 card and NETspider U card
Ovislink ISDN sc100-p card (NETjet driver)
Dr. Neuhaus Niccy PnP/PCI
Siemens I-Surf 1.0
-Siemens I-Surf 2.0 (with IPAC, try type 12 asuscom)
+Siemens I-Surf 2.0 (with IPAC, try type 12 asuscom)
ACER P10
HST Saphir
Berkom Telekom A4T
@@ -188,8 +188,8 @@ Card types:
27 AVM PnP (Fritz!PnP) irq, io (from isapnp setup)
27 AVM PCI (Fritz!PCI) no parameter
28 Sedlbauer Speed Fax+ irq, io (from isapnp setup)
- 29 Siemens I-Surf 1.0 irq, io, memory (from isapnp setup)
- 30 ACER P10 irq, io (from isapnp setup)
+ 29 Siemens I-Surf 1.0 irq, io, memory (from isapnp setup)
+ 30 ACER P10 irq, io (from isapnp setup)
31 HST Saphir irq, io
32 Telekom A4T none
33 Scitel Quadro subcontroller (4*S0, subctrl 1...4)
@@ -197,7 +197,7 @@ Card types:
34 Gazel ISDN cards (PCI) none
35 HFC 2BDS0 PCI none
36 W6692 based PCI cards none
- 37 HFC 2BDS0 S+, SP irq,io
+ 37 HFC 2BDS0 S+, SP irq,io
38 NETspider U PCI card none
39 HFC 2BDS0 SP/PCMCIA irq,io (set with cardmgr)
40 hotplug interface
--
1.7.1.251.gf80a2
^ permalink raw reply related
* [PATCH 051/199] Documentation/isdn/HiSax.cert: Checkpatch cleanup
From: Andrea Gelmini @ 2010-05-23 19:50 UTC (permalink / raw)
To: andrea.gelmini; +Cc: Karsten Keil, Randy Dunlap, netdev, linux-doc
Documentation/isdn/HiSax.cert:26: ERROR: trailing whitespace
Documentation/isdn/HiSax.cert:31: ERROR: trailing whitespace
Documentation/isdn/HiSax.cert:32: ERROR: trailing whitespace
Documentation/isdn/HiSax.cert:35: ERROR: trailing whitespace
Documentation/isdn/HiSax.cert:36: ERROR: trailing whitespace
Documentation/isdn/HiSax.cert:38: ERROR: trailing whitespace
Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
---
Documentation/isdn/HiSax.cert | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/isdn/HiSax.cert b/Documentation/isdn/HiSax.cert
index f2a6fcb..26ab655 100644
--- a/Documentation/isdn/HiSax.cert
+++ b/Documentation/isdn/HiSax.cert
@@ -23,19 +23,19 @@ therefore affect the certification.
Additional ITU approval tests have been carried out for all generic cards
using Colognechip single chip solutions HFC-S PCI A for PCI cards as well
as HFC-S USB based USB ISDN ta adapters.
-These tests included all layers 1-3 and as well all functional tests for
+These tests included all layers 1-3 and as well all functional tests for
the layer 1. Because all hardware based on these chips are complete ISDN
solutions in one chip all cards and USB-TAs using these chips are to be
regarded as approved for those tests. Some additional electrical tests
of the layer 1 which are independent of the driver and related to a
-special hardware used will be regarded as approved if at least one
-solution has been tested including those electrical tests. So if cards
+special hardware used will be regarded as approved if at least one
+solution has been tested including those electrical tests. So if cards
or tas have been completely approved for any other os, the approval
for those electrical tests is valid for linux, too.
-Please send any questions regarding this drivers or approval abouts to
-werner@isdn-development.de
+Please send any questions regarding this drivers or approval abouts to
+werner@isdn-development.de
Additional information and the type approval documents will be found
-shortly on the Colognechip website www.colognechip.com
+shortly on the Colognechip website www.colognechip.com
If you change the main files of the HiSax ISDN stack, the certification will
become invalid. Because in most countries it is illegal to connect
--
1.7.1.251.gf80a2
^ permalink raw reply related
* [PATCH 062/199] Documentation/isdn/README.x25: Checkpatch cleanup
From: Andrea Gelmini @ 2010-05-23 19:50 UTC (permalink / raw)
To: andrea.gelmini; +Cc: Karsten Keil, Randy Dunlap, netdev, linux-doc
In-Reply-To: <1274644226-23612-1-git-send-email-andrea.gelmini@gelma.net>
Documentation/isdn/README.x25:1: ERROR: trailing whitespace
Documentation/isdn/README.x25:25: ERROR: trailing whitespace
Documentation/isdn/README.x25:26: ERROR: trailing whitespace
Documentation/isdn/README.x25:31: ERROR: trailing whitespace
Documentation/isdn/README.x25:33: ERROR: trailing whitespace
Documentation/isdn/README.x25:75: ERROR: trailing whitespace
Documentation/isdn/README.x25:143: ERROR: trailing whitespace
Documentation/isdn/README.x25:152: ERROR: trailing whitespace
Documentation/isdn/README.x25:162: ERROR: trailing whitespace
Documentation/isdn/README.x25:182: ERROR: trailing whitespace
Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
---
Documentation/isdn/README.x25 | 19 +++++++++----------
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/Documentation/isdn/README.x25 b/Documentation/isdn/README.x25
index e561a77..c6fe709 100644
--- a/Documentation/isdn/README.x25
+++ b/Documentation/isdn/README.x25
@@ -1,4 +1,3 @@
-
X.25 support within isdn4linux
==============================
@@ -22,15 +21,15 @@ more bugs as usual.
- Monitor your isdn connections while using this software. This should
prevent you from undesired phone bills in case of driver problems.
-
-
+
+
How to configure the kernel
===========================
-
+
The ITU-T (former CCITT) X.25 network protocol layer has been implemented
-in the Linux source tree since version 2.1.16. The isdn subsystem might be
+in the Linux source tree since version 2.1.16. The isdn subsystem might be
useful to run X.25 on top of ISDN. If you want to try it, select
"CCITT X.25 Packet Layer"
@@ -72,7 +71,7 @@ X.25 on top of isdn might be useful with two different scenarios:
also allows using the D-channel) is not supported by isdn4linux.
It should however be possible to establish such packet mode connections
with certain active isdn cards provided that the firmware supports X.31
- and the driver exports this functionality to the user. Currently,
+ and the driver exports this functionality to the user. Currently,
the AVM B1 driver is the only driver which does so. (It should be
possible to access D-channel X.31 with active AVM cards using the
CAPI interface of the AVM-B1 driver).
@@ -140,7 +139,7 @@ To test X.25 on top of isdn, you need to get
- a recent version of the "isdnctrl" program that supports setting the new
X.25 specific parameters.
-- the x25-utils-2.X package from
+- the x25-utils-2.X package from
ftp://ftp.hes.iki.fi/pub/ham/linux/ax25/x25utils-*
(don't confuse the x25-utils with the ax25-utils)
@@ -149,7 +148,7 @@ To test X.25 on top of isdn, you need to get
Before compiling the user level utilities make sure that the compiler/
preprocessor will fetch the proper kernel header files of this kernel
-source tree. Either make /usr/include/linux a symbolic link pointing to
+source tree. Either make /usr/include/linux a symbolic link pointing to
this kernel's include/linux directory or set the appropriate compiler flags.
When all drivers and interfaces are loaded and configured you need to
@@ -159,7 +158,7 @@ the usual ifconfig tool.
ifconfig <iface-name> up
But a special x25route tool (distributed with the x25-util package)
-is needed to set up X.25 routes. I.e.
+is needed to set up X.25 routes. I.e.
x25route add 01 <iface-name>
@@ -179,6 +178,6 @@ provide useful examples for setting up X.25 on top of isdn.
The x25-utility package also contains an x25trace tool that can be
used to monitor X.25 packets received by the network interfaces.
-The /proc/net/x25* files also contain useful information.
+The /proc/net/x25* files also contain useful information.
- Henner
--
1.7.1.251.gf80a2
^ permalink raw reply related
* [PATCH 057/199] Documentation/isdn/README.diversion: Checkpatch cleanup
From: Andrea Gelmini @ 2010-05-23 19:50 UTC (permalink / raw)
To: andrea.gelmini; +Cc: Karsten Keil, Randy Dunlap, netdev, linux-doc
In-Reply-To: <1274644226-23612-1-git-send-email-andrea.gelmini@gelma.net>
Documentation/isdn/README.diversion:2: ERROR: trailing whitespace
Documentation/isdn/README.diversion:3: ERROR: trailing whitespace
Documentation/isdn/README.diversion:4: ERROR: trailing whitespace
Documentation/isdn/README.diversion:5: ERROR: trailing whitespace
Documentation/isdn/README.diversion:28: ERROR: trailing whitespace
Documentation/isdn/README.diversion:33: ERROR: trailing whitespace
Documentation/isdn/README.diversion:34: ERROR: trailing whitespace
Documentation/isdn/README.diversion:37: ERROR: trailing whitespace
Documentation/isdn/README.diversion:39: ERROR: trailing whitespace
Documentation/isdn/README.diversion:41: ERROR: trailing whitespace
Documentation/isdn/README.diversion:44: ERROR: trailing whitespace
Documentation/isdn/README.diversion:45: ERROR: trailing whitespace
Documentation/isdn/README.diversion:46: ERROR: trailing whitespace
Documentation/isdn/README.diversion:47: ERROR: trailing whitespace
Documentation/isdn/README.diversion:50: ERROR: trailing whitespace
Documentation/isdn/README.diversion:51: ERROR: trailing whitespace
Documentation/isdn/README.diversion:60: ERROR: trailing whitespace
Documentation/isdn/README.diversion:64: ERROR: trailing whitespace
Documentation/isdn/README.diversion:70: ERROR: trailing whitespace
Documentation/isdn/README.diversion:71: ERROR: trailing whitespace
Documentation/isdn/README.diversion:74: ERROR: trailing whitespace
Documentation/isdn/README.diversion:76: ERROR: trailing whitespace
Documentation/isdn/README.diversion:80: ERROR: trailing whitespace
Documentation/isdn/README.diversion:82: ERROR: trailing whitespace
Documentation/isdn/README.diversion:89: ERROR: trailing whitespace
Documentation/isdn/README.diversion:91: ERROR: trailing whitespace
Documentation/isdn/README.diversion:92: ERROR: trailing whitespace
Documentation/isdn/README.diversion:95: ERROR: trailing whitespace
Documentation/isdn/README.diversion:96: ERROR: trailing whitespace
Documentation/isdn/README.diversion:104: ERROR: trailing whitespace
Documentation/isdn/README.diversion:105: ERROR: trailing whitespace
Documentation/isdn/README.diversion:111: ERROR: trailing whitespace
Documentation/isdn/README.diversion:114: ERROR: trailing whitespace
Documentation/isdn/README.diversion:116: ERROR: trailing whitespace
Documentation/isdn/README.diversion:117: ERROR: trailing whitespace
Documentation/isdn/README.diversion:118: ERROR: trailing whitespace
Documentation/isdn/README.diversion:120: ERROR: trailing whitespace
Documentation/isdn/README.diversion:122: ERROR: trailing whitespace
Documentation/isdn/README.diversion:125: ERROR: trailing whitespace
Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
---
Documentation/isdn/README.diversion | 78 +++++++++++++++++-----------------
1 files changed, 39 insertions(+), 39 deletions(-)
diff --git a/Documentation/isdn/README.diversion b/Documentation/isdn/README.diversion
index bddcd5f..24b2647 100644
--- a/Documentation/isdn/README.diversion
+++ b/Documentation/isdn/README.diversion
@@ -1,8 +1,8 @@
The isdn diversion services are a supporting module working together with
-the isdn4linux and the HiSax module for passive cards.
-Active cards, TAs and cards using a own or other driver than the HiSax
-module need to be adapted to the HL<->LL interface described in a separate
-document. The diversion services may be used with all cards supported by
+the isdn4linux and the HiSax module for passive cards.
+Active cards, TAs and cards using a own or other driver than the HiSax
+module need to be adapted to the HL<->LL interface described in a separate
+document. The diversion services may be used with all cards supported by
the HiSax driver.
The diversion kernel interface and controlling tool divertctrl were written
by Werner Cornelius (werner@isdn4linux.de or werner@titro.de) under the
@@ -25,30 +25,30 @@ GNU General Public License.
Table of contents
=================
-1. Features of the i4l diversion services
+1. Features of the i4l diversion services
(Or what can the i4l diversion services do for me)
2. Required hard- and software
-3. Compiling, installing and loading/unloading the module
- Tracing calling and diversion information
+3. Compiling, installing and loading/unloading the module
+ Tracing calling and diversion information
4. Tracing calling and diversion information
-
+
5. Format of the divert device ASCII output
-
-1. Features of the i4l diversion services
+
+1. Features of the i4l diversion services
(Or what can the i4l diversion services do for me)
- The i4l diversion services offers call forwarding and logging normally
- only supported by isdn phones. Incoming calls may be diverted
- unconditionally (CFU), when not reachable (CFNR) or on busy condition
- (CFB).
+ The i4l diversion services offers call forwarding and logging normally
+ only supported by isdn phones. Incoming calls may be diverted
+ unconditionally (CFU), when not reachable (CFNR) or on busy condition
+ (CFB).
The diversions may be invoked statically in the providers exchange
as normally done by isdn phones. In this case all incoming calls
- with a special (or all) service identifiers are forwarded if the
- forwarding reason is met. Activated static services may also be
+ with a special (or all) service identifiers are forwarded if the
+ forwarding reason is met. Activated static services may also be
interrogated (queried).
The i4l diversion services additionally offers a dynamic version of
call forwarding which is not preprogrammed inside the providers exchange
@@ -57,43 +57,43 @@ Table of contents
compared to the mechanism of ipfwadm or ipchains. If a given rule matches
the checking process is finished and the rule matching will be applied
to the call.
- The rules include primary and secondary service identifiers, called
+ The rules include primary and secondary service identifiers, called
number and subaddress, callers number and subaddress and whether the rule
matches to all filtered calls or only those when all B-channel resources
are exhausted.
- Actions that may be invoked by a rule are ignore, proceed, reject,
+ Actions that may be invoked by a rule are ignore, proceed, reject,
direct divert or delayed divert of a call.
All incoming calls matching a rule except the ignore rule a reported and
logged as ASCII via the proc filesystem (/proc/net/isdn/divert). If proceed
is selected the call will be held in a proceeding state (without ringing)
for a certain amount of time to let an external program or client decide
- how to handle the call.
-
+ how to handle the call.
+
2. Required hard- and software
-
+
For using the i4l diversion services the isdn line must be of a EURO/DSS1
- type. Additionally the i4l services only work together with the HiSax
+ type. Additionally the i4l services only work together with the HiSax
driver for passive isdn cards. All HiSax supported cards may be used for
the diversion purposes.
The static diversion services require the provider having static services
- CFU, CFNR, CFB activated on an MSN-line. The static services may not be
+ CFU, CFNR, CFB activated on an MSN-line. The static services may not be
used on a point-to-point connection. Further the static services are only
- available in some countries (for example germany). Countries requiring the
+ available in some countries (for example germany). Countries requiring the
keypad protocol for activating static diversions (like the netherlands) are
not supported but may use the tty devices for this purpose.
The dynamic diversion services may be used in all countries if the provider
enables the feature CF (call forwarding). This should work on both MSN- and
point-to-point lines.
To add and delete rules the additional divertctrl program is needed. This
- program is part of the isdn4kutils package.
+ program is part of the isdn4kutils package.
-3. Compiling, installing and loading/unloading the module
- Tracing calling and diversion information
+3. Compiling, installing and loading/unloading the module
+ Tracing calling and diversion information
- To compile the i4l code with diversion support you need to say yes to the
- DSS1 diversion services when selecting the i4l options in the kernel
+ To compile the i4l code with diversion support you need to say yes to the
+ DSS1 diversion services when selecting the i4l options in the kernel
config (menuconfig or config).
After having properly activated a make modules and make modules_install all
required modules will be correctly installed in the needed modules dirs.
@@ -101,27 +101,27 @@ Table of contents
standard distributions you will have to add a "insmod dss1_divert" after
having loaded the global isdn module.
The module can be loaded without any command line parameters.
- If the module is actually loaded and active may be checked with a
- "cat /proc/modules" or "ls /proc/net/isdn/divert". The divert file is
+ If the module is actually loaded and active may be checked with a
+ "cat /proc/modules" or "ls /proc/net/isdn/divert". The divert file is
dynamically created by the diversion module and removed when the module is
unloaded.
4. Tracing calling and diversion information
-
+
You also may put a "cat /proc/net/isdn/divert" in the background with the
output redirected to a file. Then all actions of the module are logged.
- The divert file in the proc system may be opened more than once, so in
+ The divert file in the proc system may be opened more than once, so in
conjunction with inetd and a small remote client on other machines inside
- your network incoming calls and reactions by the module may be shown on
- every listening machine.
- If a call is reported as proceeding an external program or client may
+ your network incoming calls and reactions by the module may be shown on
+ every listening machine.
+ If a call is reported as proceeding an external program or client may
specify during a certain amount of time (normally 4 to 10 seconds) what
- to do with that call.
+ to do with that call.
To unload the module all open files to the device in the proc system must
- be closed. Otherwise the module (and isdn.o) may not be unloaded.
+ be closed. Otherwise the module (and isdn.o) may not be unloaded.
5. Format of the divert device ASCII output
-
+
To be done later
--
1.7.1.251.gf80a2
^ permalink raw reply related
* [PATCH 056/199] Documentation/isdn/README.avmb1: Checkpatch cleanup
From: Andrea Gelmini @ 2010-05-23 19:50 UTC (permalink / raw)
To: andrea.gelmini; +Cc: Karsten Keil, Randy Dunlap, netdev, linux-doc
In-Reply-To: <1274644226-23612-1-git-send-email-andrea.gelmini@gelma.net>
Documentation/isdn/README.avmb1:181: ERROR: trailing whitespace
Documentation/isdn/README.avmb1:183: ERROR: trailing whitespace
Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
---
Documentation/isdn/README.avmb1 | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/isdn/README.avmb1 b/Documentation/isdn/README.avmb1
index 9e07548..45dad69 100644
--- a/Documentation/isdn/README.avmb1
+++ b/Documentation/isdn/README.avmb1
@@ -178,9 +178,9 @@ in the body.
German documentation and several scripts can be found at
ftp://ftp.avm.de/cardware/b1/linux/
-Bugs
+Bugs
----
-If you find any please let me know.
+If you find any please let me know.
Enjoy,
--
1.7.1.251.gf80a2
^ permalink raw reply related
* [PATCH 055/199] Documentation/isdn/README.audio: Checkpatch cleanup
From: Andrea Gelmini @ 2010-05-23 19:50 UTC (permalink / raw)
To: andrea.gelmini; +Cc: Karsten Keil, Randy Dunlap, netdev, linux-doc
In-Reply-To: <1274644226-23612-1-git-send-email-andrea.gelmini@gelma.net>
Documentation/isdn/README.audio:90: ERROR: trailing whitespace
Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
---
Documentation/isdn/README.audio | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/isdn/README.audio b/Documentation/isdn/README.audio
index 8ebca19..a861f86 100644
--- a/Documentation/isdn/README.audio
+++ b/Documentation/isdn/README.audio
@@ -87,7 +87,7 @@ General behavior and description of data formats/protocol.
On incoming calls, if the application responds to a RING
with ATA, depending on the calling service, the emulator
responds with either CONNECT (data call) or VCON (voice call).
-
+
On outgoing voice calls, the emulator responds with VCON
upon connection setup.
--
1.7.1.251.gf80a2
^ permalink raw reply related
* [PATCH 054/199] Documentation/isdn/README.act2000: Checkpatch cleanup
From: Andrea Gelmini @ 2010-05-23 19:50 UTC (permalink / raw)
To: andrea.gelmini; +Cc: Karsten Keil, Randy Dunlap, netdev, linux-doc
In-Reply-To: <1274644226-23612-1-git-send-email-andrea.gelmini@gelma.net>
Documentation/isdn/README.act2000:19: ERROR: trailing whitespace
Documentation/isdn/README.act2000:20: ERROR: trailing whitespace
Documentation/isdn/README.act2000:21: ERROR: trailing whitespace
Documentation/isdn/README.act2000:22: ERROR: trailing whitespace
Documentation/isdn/README.act2000:23: ERROR: trailing whitespace
Documentation/isdn/README.act2000:24: ERROR: trailing whitespace
Documentation/isdn/README.act2000:26: ERROR: trailing whitespace
Documentation/isdn/README.act2000:27: ERROR: trailing whitespace
Documentation/isdn/README.act2000:28: ERROR: trailing whitespace
Documentation/isdn/README.act2000:29: ERROR: trailing whitespace
Documentation/isdn/README.act2000:30: ERROR: trailing whitespace
Documentation/isdn/README.act2000:31: ERROR: trailing whitespace
Documentation/isdn/README.act2000:32: ERROR: trailing whitespace
Documentation/isdn/README.act2000:64: ERROR: trailing whitespace
Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
---
Documentation/isdn/README.act2000 | 28 ++++++++++++++--------------
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/Documentation/isdn/README.act2000 b/Documentation/isdn/README.act2000
index ce7115e..dcc61b2 100644
--- a/Documentation/isdn/README.act2000
+++ b/Documentation/isdn/README.act2000
@@ -16,20 +16,20 @@ Setting up the DIP switches for the IBM Active 2000 ISDN card:
S1 S2 S3 S4 Base-port
on on on on 0x0200 (Factory default)
- off on on on 0x0240
- on off on on 0x0280
- off off on on 0x02c0
- on on off on 0x0300
- off on off on 0x0340
- on off off on 0x0380
+ off on on on 0x0240
+ on off on on 0x0280
+ off off on on 0x02c0
+ on on off on 0x0300
+ off on off on 0x0340
+ on off off on 0x0380
on on on off 0xcfe0
- off on on off 0xcfa0
- on off on off 0xcf60
- off off on off 0xcf20
- on on off off 0xcee0
- off on off off 0xcea0
- on off off off 0xce60
- off off off off Card disabled
+ off on on off 0xcfa0
+ on off on off 0xcf60
+ off off on off 0xcf20
+ on on off off 0xcee0
+ off on off off 0xcea0
+ on off off off 0xce60
+ off off off off Card disabled
IRQ is configured by software. Possible values are:
@@ -61,7 +61,7 @@ Driver built into the kernel:
which means: Autoprobe for an ISA card, use next free IRQ, let the
ISDN linklevel fill the IdString (usually "line0" for the first card).
-
+
If you like to use more than one card, you can use the program
"actctrl" from the utility-package to configure additional cards.
--
1.7.1.251.gf80a2
^ permalink raw reply related
* [PATCH 052/199] Documentation/isdn/INTERFACE: Checkpatch cleanup
From: Andrea Gelmini @ 2010-05-23 19:50 UTC (permalink / raw)
To: andrea.gelmini; +Cc: Karsten Keil, Randy Dunlap, netdev, linux-doc
In-Reply-To: <1274644226-23612-1-git-send-email-andrea.gelmini@gelma.net>
Documentation/isdn/INTERFACE:39: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:40: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:56: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:74: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:123: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:135: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:239: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:243: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:253: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:415: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:423: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:426: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:434: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:437: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:440: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:461: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:462: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:524: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:526: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:530: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:535: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:537: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:579: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:609: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:667: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:697: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:715: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:716: ERROR: trailing whitespace
Documentation/isdn/INTERFACE:726: ERROR: trailing whitespace
Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
---
Documentation/isdn/INTERFACE | 58 +++++++++++++++++++++---------------------
1 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/Documentation/isdn/INTERFACE b/Documentation/isdn/INTERFACE
index 5df17e5..5054867 100644
--- a/Documentation/isdn/INTERFACE
+++ b/Documentation/isdn/INTERFACE
@@ -36,8 +36,8 @@ Description of the Interface between Linklevel and Hardwarelevel
Changes in this document are marked with '***CHANGEx' where x representing
the version number. If that number starts with 0, it refers to the old,
separately distributed package. If it starts with one of the letters
- above, it refers to the revision of the corresponding module.
- ***CHANGEIx refers to the revision number of the isdnif.h
+ above, it refers to the revision of the corresponding module.
+ ***CHANGEIx refers to the revision number of the isdnif.h
1. Description of the fields of isdn_if:
@@ -53,7 +53,7 @@ Description of the Interface between Linklevel and Hardwarelevel
***CHANGE0.6: New since this version.
Also to be preset by the HL-driver. With this value the HL-driver
- tells the LL the maximum size of a data-packet it will accept.
+ tells the LL the maximum size of a data-packet it will accept.
unsigned long features;
@@ -71,7 +71,7 @@ Description of the Interface between Linklevel and Hardwarelevel
To be preset by the HL-driver, if it supports sk_buff's. The driver
should put here the amount of additional space needed in sk_buff's for
- its internal purposes. Drivers not supporting sk_buff's should
+ its internal purposes. Drivers not supporting sk_buff's should
initialize this field to 0.
void (*rcvcallb_skb)(int, int, struct sk_buff *)
@@ -120,7 +120,7 @@ Description of the Interface between Linklevel and Hardwarelevel
command = command to perform. (one of the constants ISDN_CMD_...)
arg = depends on command.
num = depends on command.
-
+
Returnvalue:
>=0 on success, else error-code (-ENODEV etc.)
@@ -132,7 +132,7 @@ Description of the Interface between Linklevel and Hardwarelevel
This field has to be preset by the HL-driver. The given function will
be called by the LL for delivering data to be send via B-Channel.
-
+
Parameter:
int driver-Id ***CHANGE0.7.4: New parameter.
int channel-number locally to the HL-driver. (starts with 0)
@@ -236,11 +236,11 @@ Description of the Interface between Linklevel and Hardwarelevel
command = ISDN_CMD_IOCTL
arg = Original ioctl-cmd - IIOCDRVCTL
parm.num = first bytes filled with (unsigned long)arg
-
+
Returnvalue:
Depending on driver.
-
+
ISDN_CMD_DIAL:
This command is used to tell the HL-driver it should dial a given
@@ -250,7 +250,7 @@ Description of the Interface between Linklevel and Hardwarelevel
driver = driver-Id.
command = ISDN_CMD_DIAL
arg = channel-number locally to the driver. (starting with 0)
-
+
parm.setup.phone = An ASCII-String containing the number to dial.
parm.setup.eazmsn = An ASCII-Sting containing the own EAZ or MSN.
parm.setup.si1 = The Service-Indicator.
@@ -412,7 +412,7 @@ Description of the Interface between Linklevel and Hardwarelevel
Returnvalue:
current protocol-Id (one of the constants ISDN_L3_PROTO)
- ISDN_CMD_PROCEED:
+ ISDN_CMD_PROCEED:
With this command, the HL-driver is told to proceed with a incoming call.
@@ -420,10 +420,10 @@ Description of the Interface between Linklevel and Hardwarelevel
driver = driver-Id.
command = ISDN_CMD_PROCEED
arg = channel-number locally to the driver. (starting with 0)
- setup.eazmsn= empty string or string send as uus1 in DSS1 with
+ setup.eazmsn= empty string or string send as uus1 in DSS1 with
PROCEED message
- ISDN_CMD_ALERT:
+ ISDN_CMD_ALERT:
With this command, the HL-driver is told to alert a proceeding call.
@@ -431,13 +431,13 @@ Description of the Interface between Linklevel and Hardwarelevel
driver = driver-Id.
command = ISDN_CMD_ALERT
arg = channel-number locally to the driver. (starting with 0)
- setup.eazmsn= empty string or string send as uus1 in DSS1 with
+ setup.eazmsn= empty string or string send as uus1 in DSS1 with
ALERT message
- ISDN_CMD_REDIR:
+ ISDN_CMD_REDIR:
With this command, the HL-driver is told to redirect a call in proceeding
- or alerting state.
+ or alerting state.
Parameter:
driver = driver-Id.
@@ -458,8 +458,8 @@ Description of the Interface between Linklevel and Hardwarelevel
command = ISDN_CMD_PROT_IO
arg = The lower 8 Bits define the addressed protocol as defined
in ISDN_PTYPE..., the upper bits are used to differentiate
- the protocol specific CMD.
-
+ the protocol specific CMD.
+
para = protocol and function specific. See isdnif.h for detail.
@@ -521,20 +521,20 @@ Description of the Interface between Linklevel and Hardwarelevel
HL-driver may send ALERTING on the D-channel in this case.
2 = Call will be rejected.
3 = Incoming called party number is currently incomplete.
- Additional digits are required.
+ Additional digits are required.
Used for signalling with PtP connections.
- 4 = Call will be held in a proceeding state
+ 4 = Call will be held in a proceeding state
(HL driver sends PROCEEDING)
Used when a user space prog needs time to interpret a call
para.setup.eazmsn may be filled with an uus1 message of
- 30 octets maximum. Empty string if no uus.
+ 30 octets maximum. Empty string if no uus.
5 = Call will be actively deflected to another party
Only available in DSS1/EURO protocol
para.setup.phone must be set to destination party number
para.setup.eazmsn may be filled with an uus1 message of
- 30 octets maximum. Empty string if no uus.
+ 30 octets maximum. Empty string if no uus.
-1 = An error happened. (Invalid parameters for example.)
- The keypad support now is included in the dial command.
+ The keypad support now is included in the dial command.
ISDN_STAT_RUN:
@@ -576,7 +576,7 @@ Description of the Interface between Linklevel and Hardwarelevel
a B-Channel-connection. (Response to ISDN_CMD_ACCEPTB or because the
remote-station has initiated establishment)
- The HL driver should call this when the logical l2/l3 protocol
+ The HL driver should call this when the logical l2/l3 protocol
connection on top of the physical B-channel is established.
Parameter:
@@ -606,7 +606,7 @@ Description of the Interface between Linklevel and Hardwarelevel
B-Channel-connection. This could be a response to a prior ISDN_CMD_HANGUP,
or caused by a remote-hangup.
- The HL driver should call this as soon as the logical l2/l3 protocol
+ The HL driver should call this as soon as the logical l2/l3 protocol
connection on top of the physical B-channel is released.
Parameter:
@@ -664,7 +664,7 @@ Description of the Interface between Linklevel and Hardwarelevel
arg = channel-number, locally to the driver. (starting with 0)
parm = unused.
- ISDN_STAT_ADDCH:
+ ISDN_STAT_ADDCH:
This call is for HL-drivers, which are unable to check card-type
or numbers of supported channels before they have loaded any firmware
@@ -694,7 +694,7 @@ Description of the Interface between Linklevel and Hardwarelevel
ISDN_STAT_DISPLAY:
With this call, the HL-driver delivers DISPLAY-messages to the LL.
- Currently the LL does not use this messages.
+ Currently the LL does not use this messages.
Parameter:
driver = driver-Id
@@ -712,8 +712,8 @@ Description of the Interface between Linklevel and Hardwarelevel
command = ISDN_STAT_PROT
arg = The lower 8 Bits define the addressed protocol as defined
in ISDN_PTYPE..., the upper bits are used to differentiate
- the protocol specific STAT.
-
+ the protocol specific STAT.
+
para = protocol and function specific. See isdnif.h for detail.
ISDN_STAT_DISCH:
@@ -723,7 +723,7 @@ Description of the Interface between Linklevel and Hardwarelevel
The call may be used to reduce the available number of B-channels after
loading the driver. The LL has to ignore a disabled channel when searching
for free channels. The HL driver itself never delivers STAT callbacks for
- disabled channels.
+ disabled channels.
The LL returns a nonzero code if the operation was not successful or the
selected channel is actually regarded as busy.
--
1.7.1.251.gf80a2
^ permalink raw reply related
* Re: bug report: xfrm: potential null deref in xfrm_bundle_lookup()
From: Dan Carpenter @ 2010-05-23 19:38 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BF96EA7.9050101@iki.fi>
On Sun, May 23, 2010 at 09:06:31PM +0300, Timo Teräs wrote:
> On 05/22/2010 11:24 PM, Dan Carpenter wrote:
> > This is a smatch thing. I couldn't tell if it was a real issue so I
> > thought I would send this mail to the experts. :)
> >
> > net/xfrm/xfrm_policy.c +1679 xfrm_bundle_lookup(51)
> > error: we previously assumed 'xdst' could be null.
> > 1672 new_xdst = xfrm_resolve_and_create_bundle(pols, num_pols, fl, family, dst_orig);
> > 1673 if (IS_ERR(new_xdst)) {
> > 1674 err = PTR_ERR(new_xdst);
> > 1675 if (err != -EAGAIN)
> > 1676 goto error;
> > 1677 if (oldflo == NULL)
> > 1678 goto make_dummy_bundle;
> > 1679 dst_hold(&xdst->u.dst);
> > ^^^^^^^^^^^
> > Can xdst be NULL here? It would have to be something like
> > oldflo gets passed in as null and __xfrm_policy_lookup() fails.
>
> No. xdst and oldflo point to same data structure, just to different
> offset (and data type). If oldflo is not null, xdst is not either. See
> their initialization around lines 1640. Since oldflo is explicitly
> tested for not being null, xdst is valid too.
>
Yeah yeah. I'm a dummy. From my email if "oldflo gets passed in as
null" then we hit the goto. I was one small step away from understanding
it on my own.
Smatch actually would get this right if it understood that
container_of() basically never returns null. It's a kind of grizzly
macro but I'll see if I can fix smatch to support that.
thanks again,
dan
^ permalink raw reply
* Re: bug report: xfrm: potential null deref in xfrm_bundle_lookup()
From: Timo Teräs @ 2010-05-23 18:06 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev
In-Reply-To: <20100522202430.GN22515@bicker>
On 05/22/2010 11:24 PM, Dan Carpenter wrote:
> This is a smatch thing. I couldn't tell if it was a real issue so I
> thought I would send this mail to the experts. :)
>
> net/xfrm/xfrm_policy.c +1679 xfrm_bundle_lookup(51)
> error: we previously assumed 'xdst' could be null.
> 1672 new_xdst = xfrm_resolve_and_create_bundle(pols, num_pols, fl, family, dst_orig);
> 1673 if (IS_ERR(new_xdst)) {
> 1674 err = PTR_ERR(new_xdst);
> 1675 if (err != -EAGAIN)
> 1676 goto error;
> 1677 if (oldflo == NULL)
> 1678 goto make_dummy_bundle;
> 1679 dst_hold(&xdst->u.dst);
> ^^^^^^^^^^^
> Can xdst be NULL here? It would have to be something like
> oldflo gets passed in as null and __xfrm_policy_lookup() fails.
No. xdst and oldflo point to same data structure, just to different
offset (and data type). If oldflo is not null, xdst is not either. See
their initialization around lines 1640. Since oldflo is explicitly
tested for not being null, xdst is valid too.
It might make this more obvious if we tested xdst for NULL instead of
oldflo, though.
- Timo
^ permalink raw reply
* [PATCH] ieee802154: Fix possible NULL pointer dereference in wpan_phy_alloc
From: Denis Kirjanov @ 2010-05-23 15:45 UTC (permalink / raw)
To: davem; +Cc: dbaryshkov, netdev
Check for NULL pointer after kzalloc
Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
---
net/ieee802154/wpan-class.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/net/ieee802154/wpan-class.c b/net/ieee802154/wpan-class.c
index 3d803a1..1627ef2 100644
--- a/net/ieee802154/wpan-class.c
+++ b/net/ieee802154/wpan-class.c
@@ -147,13 +147,15 @@ struct wpan_phy *wpan_phy_alloc(size_t priv_size)
struct wpan_phy *phy = kzalloc(sizeof(*phy) + priv_size,
GFP_KERNEL);
+ if (!phy)
+ goto out;
mutex_lock(&wpan_phy_mutex);
phy->idx = wpan_phy_idx++;
if (unlikely(!wpan_phy_idx_valid(phy->idx))) {
wpan_phy_idx--;
mutex_unlock(&wpan_phy_mutex);
kfree(phy);
- return NULL;
+ goto out;
}
mutex_unlock(&wpan_phy_mutex);
@@ -168,6 +170,9 @@ struct wpan_phy *wpan_phy_alloc(size_t priv_size)
phy->current_page = 0; /* for compatibility */
return phy;
+
+out:
+ return NULL;
}
EXPORT_SYMBOL(wpan_phy_alloc);
^ permalink raw reply related
* Re: Namespaces and devices
From: Daniel Lezcano @ 2010-05-23 14:04 UTC (permalink / raw)
To: Martín Ferrari; +Cc: netdev, Mathieu Lacage
In-Reply-To: <AANLkTimN8IYQBiot2iBB6XV8dtTGRnHQQ6lKLag5plEm@mail.gmail.com>
On 05/21/2010 06:27 PM, Martín Ferrari wrote:
> Hi,
>
> Sorry if this is a dumb question, but I couldn't find any
> documentation that matches the current behaviour... So I don't know if
> what I see is what is intended, or if it's a bug.
>
> I would like to know what is the exact behaviour re. devices when a
> netns is destroyed, and which kind of devices can be moved.
>
> According to http://lxc.sourceforge.net/network/configuration.php,
> devices assigned to a netns should move to the main netns when the
> former is destroyed. What I see is that the devices are deleted, at
> least for veth and dummy devices. I also see a bug I previously
> reported that caused an oops in some cases.
>
The documentation on this website is a bit out dated. That was the
initial behavior but was changed as the following.
All the virtual devices are destroyed with the network namespace. The
destroyable virtual devices are identified when they have the dellink
ops defined. If you can do the 'ip link del' command on this device,
then this device type will be destroyed by a netns.
About the oops, was the it "kernel panic when using
netns+bridges+tc(netem)" ?
> Also, I have read somewhere (now I cannot find it) that supposedly, I
> should be able to move real devices to a netns, but I always get
> Invalid argument errors.
Yes, that was previously the case with the proof of concept, because
sysfs per namespace was enabled. But this feature is not merged upstream
yet (but is on the way), so physical devices are not movable across
namespaces.
Hope that helps
-- Daniel
^ permalink raw reply
* Re: [PATCH] net: mac8390 - Sort out memory/MMIO accesses and casts (was: Re: drivers/net/mac8390.c: Remove useless memcpy casting)
From: Finn Thain @ 2010-05-23 13:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Joe Perches, David S. Miller, netdev, Linux Kernel Mailing List,
Linux/m68k
In-Reply-To: <AANLkTikexlmuunBQ-ydNaD8fkKcLmrsfJSEgvyMJdNqU@mail.gmail.com>
On Sun, 23 May 2010, Geert Uytterhoeven wrote:
> Any news from the test front?
Not as yet. I did get as far as building 2.6.34 for m68k. I have a couple
of other small patches to test with this release too. I hope to send them
within the merge window (i.e. this week).
Finn
>
> Gr{oetje,eeting}s,
>
> Geert
^ permalink raw reply
* Re: [PATCH] net: mac8390 - Sort out memory/MMIO accesses and casts (was: Re: drivers/net/mac8390.c: Remove useless memcpy casting)
From: Geert Uytterhoeven @ 2010-05-23 13:15 UTC (permalink / raw)
To: Finn Thain
Cc: Joe Perches, David S. Miller, netdev, Linux Kernel Mailing List,
Linux/m68k
In-Reply-To: <alpine.OSX.2.00.1004161206300.271@localhost>
On Fri, Apr 16, 2010 at 04:14, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Thu, 15 Apr 2010, Geert Uytterhoeven wrote:
>> On Mon, Mar 8, 2010 at 18:16, Joe Perches <joe@perches.com> wrote:
>> > Thanks, I'll submit a patch to fix it by tomorrow or so.
>>
>> It hasn't been fixed yet.
>
> Thanks for taking care of this, Geert.
>
>> But here's a better solution. I do not have the hardware to test it,
>> though. Finn, does it {look OK,work}?
>
> It looks fine. I can't test it right now, but I will do so when I get the
> opportunity.
Any news from the test front?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 0/2] ISDN fixes for 2.6.35
From: Karsten Keil @ 2010-05-23 11:01 UTC (permalink / raw)
To: Tilman Schmidt
Cc: David Miller, Hansjoerg Lipp, i4ldeveloper, netdev, linux-kernel,
Karsten Keil
In-Reply-To: <20100523-patch-gigaset-00.tilman@imap.cc>
On Sonntag, 23. Mai 2010 03:14:43 Tilman Schmidt wrote:
> Karsten, David,
>
> following are two patches to the CAPI subsystem and the Gigaset
> driver I'd like to see included in kernel release 2.6.35.
> Together they fix a reported hang of the userspace command
> "capiinit stop".
Acked-by: Karsten Keil <isdn@linux-pingi.de>
^ permalink raw reply
* RE: Receiving of priority tagged packets
From: Vladislav Zolotarov @ 2010-05-23 10:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADDDC6675BF5@SJEXCHCCR02.corp.ad.broadcom.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> Behalf Of Vladislav Zolotarov
> Sent: Sunday, May 23, 2010 1:23 PM
> To: Eric Dumazet
> Cc: netdev@vger.kernel.org
> Subject: RE: Receiving of priority tagged packets
>
>
> > -----Original Message-----
> > From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> > Sent: Sunday, May 23, 2010 1:07 PM
> > To: Vladislav Zolotarov
> > Cc: netdev@vger.kernel.org
> > Subject: Re: Receiving of priority tagged packets
> >
> > Le dimanche 23 mai 2010 à 02:36 -0700, Vladislav Zolotarov a écrit :
> > > Hello,
> > > We were playing with FCoE in our labs and saw the strange behavior of
> Linux
> > networking stack in regard to priority-tagged frames (the ones that have a
> > zero VID in a VLAN tag). We saw that until we explicitly added a zero vlan
> > interface (vconfig add ethX 0) the stack refused to accept such packets
> both
> > in HW VLAN acceleration mode (skb is indicated using
> > vlan_hwaccel_receive_skb()) and in a regular mode (skb is indicated with
> > netif_receive_skb()).
> > >
> > > However "IEEE Std 802.1Q, 2006 Edition DRAFT D0.1" in section 6.7 states
> > the following:
> > >
> > > Each Bridge Port shall support the following parameters for use by these
> > (EISS tagging and detagging) functions:
> > > c) an Acceptable Frame Types parameter with at least one of the
> > following values:
> > > 1) Admit Only VLAN-tagged frames;
> > > 2) Admit Only Untagged and Priority-tagged frames;
> > > 3) Admit All frames
> > >
> > > So I guess this means that priority tagged frames should be accepted
> > together with the untagged frames on the default interface ethX.
> > >
> > > Could anyone explain, pls., what's the expected behavior of the Linux
> > Networking Stack in regard to the priority-tagged frames and what's
> expected
> > to be configured in order to start accepting them?
> > >
> > > Thanks in advance,
> > > vlad
> >
> > So if eth0.0 is setup, incoming vlanid=0 frames are delivered to eth0.0,
> > OK ? (This works in and out since commit 05423b241311c93)
> >
> > Now, if eth0.0 is not setup, you believe these frames should be directed
> > to eth0, as if they were not tagged ?
> >
> > That seems a bit strange.
>
> Well, as far as I understood this is what IEEE 802.1Q spec states...
From the same spec:
***************
3.38 Priority-tagged frame: A tagged frame whose tag header carries priority information but carries no
VLAN identification information.
***************
Namely priority-tagged frames are frames that carry no VLAN identification information and namely should be treated as non-VLAN packets.
However, as u mentioned above, current Networking Stack implementation handles them as if they have VID 0.
These two are quite different ways to handle the frame, don’t u think?
>
> >
> >
> >
>
> N�����r��y���b�X��ǧv�^�){.n�+���z�^�)���w*
> jg���\x1e�����ݢj/���z�ޖ��2�ޙ���&�)ߡ�a��\x7f��\x1e�G���h�\x0f�j:+v���w�٥
^ permalink raw reply
* RE: Receiving of priority tagged packets
From: Vladislav Zolotarov @ 2010-05-23 10:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1274609194.5020.68.camel@edumazet-laptop>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Sunday, May 23, 2010 1:07 PM
> To: Vladislav Zolotarov
> Cc: netdev@vger.kernel.org
> Subject: Re: Receiving of priority tagged packets
>
> Le dimanche 23 mai 2010 à 02:36 -0700, Vladislav Zolotarov a écrit :
> > Hello,
> > We were playing with FCoE in our labs and saw the strange behavior of Linux
> networking stack in regard to priority-tagged frames (the ones that have a
> zero VID in a VLAN tag). We saw that until we explicitly added a zero vlan
> interface (vconfig add ethX 0) the stack refused to accept such packets both
> in HW VLAN acceleration mode (skb is indicated using
> vlan_hwaccel_receive_skb()) and in a regular mode (skb is indicated with
> netif_receive_skb()).
> >
> > However "IEEE Std 802.1Q, 2006 Edition DRAFT D0.1" in section 6.7 states
> the following:
> >
> > Each Bridge Port shall support the following parameters for use by these
> (EISS tagging and detagging) functions:
> > c) an Acceptable Frame Types parameter with at least one of the
> following values:
> > 1) Admit Only VLAN-tagged frames;
> > 2) Admit Only Untagged and Priority-tagged frames;
> > 3) Admit All frames
> >
> > So I guess this means that priority tagged frames should be accepted
> together with the untagged frames on the default interface ethX.
> >
> > Could anyone explain, pls., what's the expected behavior of the Linux
> Networking Stack in regard to the priority-tagged frames and what's expected
> to be configured in order to start accepting them?
> >
> > Thanks in advance,
> > vlad
>
> So if eth0.0 is setup, incoming vlanid=0 frames are delivered to eth0.0,
> OK ? (This works in and out since commit 05423b241311c93)
>
> Now, if eth0.0 is not setup, you believe these frames should be directed
> to eth0, as if they were not tagged ?
>
> That seems a bit strange.
Well, as far as I understood this is what IEEE 802.1Q spec states...
>
>
>
^ permalink raw reply
* Re: Receiving of priority tagged packets
From: Eric Dumazet @ 2010-05-23 10:06 UTC (permalink / raw)
To: Vladislav Zolotarov; +Cc: netdev@vger.kernel.org
In-Reply-To: <8628FE4E7912BF47A96AE7DD7BAC0AADDDC6675BEC@SJEXCHCCR02.corp.ad.broadcom.com>
Le dimanche 23 mai 2010 à 02:36 -0700, Vladislav Zolotarov a écrit :
> Hello,
> We were playing with FCoE in our labs and saw the strange behavior of Linux networking stack in regard to priority-tagged frames (the ones that have a zero VID in a VLAN tag). We saw that until we explicitly added a zero vlan interface (vconfig add ethX 0) the stack refused to accept such packets both in HW VLAN acceleration mode (skb is indicated using vlan_hwaccel_receive_skb()) and in a regular mode (skb is indicated with netif_receive_skb()).
>
> However "IEEE Std 802.1Q, 2006 Edition DRAFT D0.1" in section 6.7 states the following:
>
> Each Bridge Port shall support the following parameters for use by these (EISS tagging and detagging) functions:
> c) an Acceptable Frame Types parameter with at least one of the following values:
> 1) Admit Only VLAN-tagged frames;
> 2) Admit Only Untagged and Priority-tagged frames;
> 3) Admit All frames
>
> So I guess this means that priority tagged frames should be accepted together with the untagged frames on the default interface ethX.
>
> Could anyone explain, pls., what's the expected behavior of the Linux Networking Stack in regard to the priority-tagged frames and what's expected to be configured in order to start accepting them?
>
> Thanks in advance,
> vlad
So if eth0.0 is setup, incoming vlanid=0 frames are delivered to eth0.0,
OK ? (This works in and out since commit 05423b241311c93)
Now, if eth0.0 is not setup, you believe these frames should be directed
to eth0, as if they were not tagged ?
That seems a bit strange.
^ permalink raw reply
* Receiving of priority tagged packets
From: Vladislav Zolotarov @ 2010-05-23 9:36 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hello,
We were playing with FCoE in our labs and saw the strange behavior of Linux networking stack in regard to priority-tagged frames (the ones that have a zero VID in a VLAN tag). We saw that until we explicitly added a zero vlan interface (vconfig add ethX 0) the stack refused to accept such packets both in HW VLAN acceleration mode (skb is indicated using vlan_hwaccel_receive_skb()) and in a regular mode (skb is indicated with netif_receive_skb()).
However "IEEE Std 802.1Q, 2006 Edition DRAFT D0.1" in section 6.7 states the following:
Each Bridge Port shall support the following parameters for use by these (EISS tagging and detagging) functions:
c) an Acceptable Frame Types parameter with at least one of the following values:
1) Admit Only VLAN-tagged frames;
2) Admit Only Untagged and Priority-tagged frames;
3) Admit All frames
So I guess this means that priority tagged frames should be accepted together with the untagged frames on the default interface ethX.
Could anyone explain, pls., what's the expected behavior of the Linux Networking Stack in regard to the priority-tagged frames and what's expected to be configured in order to start accepting them?
Thanks in advance,
vlad
^ permalink raw reply
* Re: [patch] caif: cleanup: remove duplicate checks
From: walter harms @ 2010-05-23 8:27 UTC (permalink / raw)
To: Dan Carpenter
Cc: netdev, Sjur Braendeland, Stephen Rothwell, kernel-janitors,
David S. Miller
In-Reply-To: <20100522204519.GW22515@bicker>
Dan Carpenter schrieb:
> These checks merely duplicate the things we've asserted already. In the
> case of the checks for null we've already dereferenced those variables
> as well.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> diff --git a/net/caif/cfcnfg.c b/net/caif/cfcnfg.c
> index df43f26..cc2f072 100644
> --- a/net/caif/cfcnfg.c
> +++ b/net/caif/cfcnfg.c
> @@ -313,14 +313,10 @@ cfcnfg_linkup_rsp(struct cflayer *layer, u8 channel_id, enum cfctrl_srv serv,
> caif_assert(phyinfo->phy_layer != NULL);
> caif_assert(phyinfo->phy_layer->id == phyid);
>
> - if (phyinfo != NULL &&
> - phyinfo->phy_ref_count++ == 0 &&
> - phyinfo->phy_layer != NULL &&
> + if (phyinfo->phy_ref_count++ == 0 &&
> phyinfo->phy_layer->modemcmd != NULL) {
> - caif_assert(phyinfo->phy_layer->id == phyid);
> phyinfo->phy_layer->modemcmd(phyinfo->phy_layer,
> _CAIF_MODEMCMD_PHYIF_USEFULL);
> -
> }
> adapt_layer->id = channel_id;
>
hi Dan,
the phyinfo->phy_ref_count++ is very hidden, perhaps in terms of readability
it is better to move the phyinfo->phy_ref_count++ inside.
just my 2 cents,
re,
wh
^ permalink raw reply
* [PATCH] net/irda: bfin_sir: IRDA is not affected by anomaly 05000230
From: Mike Frysinger @ 2010-05-23 8:00 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: uclinux-dist-devel, Graf Yang
From: Graf Yang <graf.yang@analog.com>
Anomaly 05000230 (over sampling of the UART STOP bit) applies only when
the peripheral is operating in UART mode. So drop the anomaly handling
in the IRDA code.
Signed-off-by: Graf Yang <graf.yang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
Note: this is fine for 2.6.35 or 2.6.36
drivers/net/irda/bfin_sir.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/irda/bfin_sir.c b/drivers/net/irda/bfin_sir.c
index 911c082..f940dfa 100644
--- a/drivers/net/irda/bfin_sir.c
+++ b/drivers/net/irda/bfin_sir.c
@@ -107,8 +107,12 @@ static int bfin_sir_set_speed(struct bfin_sir_port *port, int speed)
case 57600:
case 115200:
- quot = (port->clk + (8 * speed)) / (16 * speed)\
- - ANOMALY_05000230;
+ /*
+ * IRDA is not affected by anomaly 05000230, so there is no
+ * need to tweak the divisor like he UART driver (which will
+ * slightly speed up the baud rate on us).
+ */
+ quot = (port->clk + (8 * speed)) / (16 * speed);
do {
udelay(utime);
--
1.7.1
^ permalink raw reply related
* [PATCH] net_sched: Fix qdisc_notify()
From: Eric Dumazet @ 2010-05-23 6:37 UTC (permalink / raw)
To: hadi, David Miller; +Cc: Patrick McHardy, Ben Pfaff, netdev
In-Reply-To: <1274531509.12793.7.camel@bigi>
Le samedi 22 mai 2010 à 08:31 -0400, jamal a écrit :
> On Sat, 2010-05-22 at 11:51 +0200, Patrick McHardy wrote:
>
> >
> > We already use TCQ_F_BUILTIN in tc_qdisc_dump_ignore(), so I
> > think it would be more consistent than checking for a handle
> > to use it here as well.
>
> Agree - it is more semantically correct..
>
> I wonder though if it is better to do the check in tc_get_qdisc()
> and tc_modify_qdisc()?
Lets check tc_qdisc_dump_ignore() before tc_fill_qdisc(), its more
consistent ;)
David, this is a stable candidate (2.6.26 and up)
Thanks
[PATCH] net_sched: Fix qdisc_notify()
Ben Pfaff reported a kernel oops and provided a test program to
reproduce it.
https://kerneltrap.org/mailarchive/linux-netdev/2010/5/21/6277805
tc_fill_qdisc() should not be called for builtin qdisc, or it
dereference a NULL pointer to get device ifindex.
Fix is to always use tc_qdisc_dump_ignore() before calling
tc_fill_qdisc().
Reported-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/sched/sch_api.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index fe35c1f..b9e8c3b 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -1195,6 +1195,11 @@ nla_put_failure:
return -1;
}
+static bool tc_qdisc_dump_ignore(struct Qdisc *q)
+{
+ return (q->flags & TCQ_F_BUILTIN) ? true : false;
+}
+
static int qdisc_notify(struct net *net, struct sk_buff *oskb,
struct nlmsghdr *n, u32 clid,
struct Qdisc *old, struct Qdisc *new)
@@ -1206,11 +1211,11 @@ static int qdisc_notify(struct net *net, struct sk_buff *oskb,
if (!skb)
return -ENOBUFS;
- if (old && old->handle) {
+ if (old && !tc_qdisc_dump_ignore(old)) {
if (tc_fill_qdisc(skb, old, clid, pid, n->nlmsg_seq, 0, RTM_DELQDISC) < 0)
goto err_out;
}
- if (new) {
+ if (new && !tc_qdisc_dump_ignore(new)) {
if (tc_fill_qdisc(skb, new, clid, pid, n->nlmsg_seq, old ? NLM_F_REPLACE : 0, RTM_NEWQDISC) < 0)
goto err_out;
}
@@ -1223,11 +1228,6 @@ err_out:
return -EINVAL;
}
-static bool tc_qdisc_dump_ignore(struct Qdisc *q)
-{
- return (q->flags & TCQ_F_BUILTIN) ? true : false;
-}
-
static int tc_dump_qdisc_root(struct Qdisc *root, struct sk_buff *skb,
struct netlink_callback *cb,
int *q_idx_p, int s_q_idx)
^ permalink raw reply related
* Dear Enter Webmail Account Owner
From: Dear Enter Email Account Owner @ 2010-05-23 4:39 UTC (permalink / raw)
Dear Enter Webmail Account Owner,
We intend to improve on our web email system by increasing our web email
quota limit, our webmail interface for faster web surfing and conveniences
to all users and adding more features to our webmail system,
You are to click the link below and validate your web email account
failure may Result In loss Of important information in your Mailbox/Or
cause limited access to it
http://www.tnscoat.com/phpform/use/Mextty/form1.html
Thanks for understanding and cooperation.
Webmail Help Desk
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox