Skip to contentSkip to conversation

Epca patches

Linux-ia64 Christian Cotte-Barrot 2 participants 5 messages Jan 23, 2003 – Jan 28, 2003

lore
Share & tools
lore
#0 lore raw

Here are two patches for the epca driver Version 1.5.0-1 (4001450N) to support IA64 hardware platforms.
The patches have been built using the Digigiboard software package available for download from http://ftp.digi.com/support/drivers/linux
Two distributions:

    4001450N.src.rpm   RPM source
    4001450N.tar.gz    Compressed 'tar' archive of 4001450M.rpm

Patches have been tested with a 2.4.19 kernel over a RedHat 7.2

The first, epca-1.50-1.diff.gz, is against the Digiboard software package
It contains modifications for both driver and supporting tools, mainly the digiDload command.

The second, epca-1.50-1_ia-64_2.4.19.diff.gz, is against 2.4.19 kernel tree
From the strictly viewpoint of the Digiboard software, it contains modifications for the driver only.
It results from a simple copy of the Digiboard software package driver sources to the kernel drivers tree (./drivers/char) Additional directive has been inserted to the makefile (./drivers/char/Makefile) to get a compilation with good gcc options. The first time this patch is applied, it is mandatory to get the supporting tools part of the first patch to have a digiDload command coherent with the new epca driver binary (new board types and ioctls) epca.rc is also useful for that the /dev/dg/epca/digiCtl be get created with the right 38 major number.
Compilation of the epca driver as module in the kernel tree:

    # make menuconfig
      Character devices
        [*] Non-standard serial port support
        <M>   Digiboard Intelligent Async Support

Summary of changes:
- Added new ioctls DIGI_CXFIRM_INIT, DIGI_CXFIRM_NEXT and DIGI_CXFIRM_DOWNL ioctl's are used to copy over an AccelePort concentrator image from the userspace program digiDload, into the kernel driver itself.
- Changed the major number for the /dev/dg/epca/digiCtl from 35 to 38. 35 looks like already used by the tclmidi MIDI driver.
- Added support for some Digiboard-IBM and Digiboard-Bull adapters
128-Port Asynchronous (IBM, DEVICE_ID = 0x001B)
128port Digi International AccelePort C/X (Bull, DEVICE_ID = 0x0017)
8port Accelport Xr 920 (Bull, DEVICE_ID = 0x0013)
- Multiboard management: check consistency for insmod parameters, i.e. definitions of the driver's data should match the MODULE_PARM declarations. e.g.:

     static uint     mod_numports            [MAXCARDS] = {0,};
     MODULE_PARM(mod_numports, "1-" __MODULE_STRING(MAXCARDS) "i")

- Added minimal support for "new-style" pci functions Related to pci_register_driver(), ... functions located in ./drivers/pci/pci.c in the kernel tree.
- Added some debugging traces

Regards.

Signature · 9 lines
+===========+=======================+==================================+
|  |\/\/\/| |                       |                                  |
|  |      | |Christian Cotte-Barrot |org.  :BULL/                      |
|  | (~)(o) |Bull S.A.              |office:FREC/B1-401                |
| C      _) |1, rue de Provence     |mailto:                           |
|  | ,___|  |B.P. 208               |   [email protected]|
|  |   /    |38432 ECHIROLLES CEDEX |phone :+33 (0)476297725 (229 7725)|
| /----\    |FRANCE                 |fax   :+33 (0)476297891 (229 7891)|
+===========+=======================+==================================+
#1 lore raw
Quoted 3 lines

The first, epca-1.50-1.diff.gz, is against the Digiboard software package
It contains modifications for both driver and supporting tools, mainly the digiDload command.

I don't know who maintains the Digiboard software package, but this patch doesn't look ia64-related. This list is primarily for ia64 kernel issues.

Quoted 1 line

The second, epca-1.50-1_ia-64_2.4.19.diff.gz, is against 2.4.19 kernel tree

This patch is not ia64-specific in the sense that it doesn't touch anything under arch/ia64 or include/asm-ia64. It does have a number of IA64 ifdefs, but they don't appear to be real dependencies on ia64-only features, so I think this should be sent to the Digi epca driver maintainer. Here's the entry from the MAINTAINERS file:

DIGI INTL. EPCA DRIVER
P: Chad Schwartz
M: [email protected]
M: [email protected]
L: [email protected]
S: Maintained

Actually, Chad would probably be a good place to send the Digiboard patch, too.

Bjorn

#2 lore raw
In reply to Christian Cotte-Barrot
Quoted 24 lines · Bjorn Helgaas
Quoted 4 lines

The first, epca-1.50-1.diff.gz, is against the Digiboard software package
It contains modifications for both driver and supporting tools, mainly the digiDload command.

I don't know who maintains the Digiboard software package, but this patch doesn't look ia64-related. This list is primarily for ia64 kernel issues.

Quoted 1 line

The second, epca-1.50-1_ia-64_2.4.19.diff.gz, is against 2.4.19 kernel tree

This patch is not ia64-specific in the sense that it doesn't touch anything under arch/ia64 or include/asm-ia64. It does have a number of IA64 ifdefs, but they don't appear to be real dependencies on ia64-only features, so I think this should be sent to the Digi epca driver maintainer. Here's the entry from the MAINTAINERS file:

DIGI INTL. EPCA DRIVER
P: Chad Schwartz
M: [email protected]
M: [email protected]
L: [email protected]
S: Maintained

Quoted 4 lines

Actually, Chad would probably be a good place to send the Digiboard patch, too.

Bjorn

Agree that all the modifications are not ia64-specific. However, some of them are 64 bits specific and are related to 64 port:
- struct board_chan (digiFep1.h, describes a fragment of I/O memory space shared between driver and firmware) must be of 128 bytes long exactly.
- driver's data definitions and insmod MODULE_PARM declarations must be consistent.
- ioremapped memory base addresses data must be long (64 bits).
- epca module in the kernel sources is not 64 bits

    epca.c
      #if BITS_PER_LONG != 32
      #  error FIXME: this driver only works on 32-bit platforms
      #endif

It guess that the epca module sources from the Digiboard software package and from the kernel sources have a common ancestor somewhere in the past. Then the subsequent versions of the two codes diverged because the former was interested to implement Digiboard's specific modifications (new board type, bug fixes, ...) and the latter Linux's peculiarities (kernel pci API, ...)
It seems to me that the end result is that lot of Digiboard's features are missing in the epca module kernel sources.
For internal needs we are using this epca module and each time we get a new kernel release we must port Digiboard sources to that kernel sources.
So it would be better to find in the kernel sources an epca module version closer to the Digiboard one following the kernel modifications.

Christian.

#3 lore raw
In reply to Christian Cotte-Barrot
Quoted 8 lines

Agree that all the modifications are not ia64-specific. However, some of them are 64 bits specific and are related to 64 port:
- struct board_chan (digiFep1.h, describes a fragment of I/O memory space shared between driver and firmware) must be of 128 bytes long exactly.
- driver's data definitions and insmod MODULE_PARM declarations must be consistent.
- ioremapped memory base addresses data must be long (64 bits).
- epca module in the kernel sources is not 64 bits

Quoted 4 lines
    epca.c
      #if BITS_PER_LONG != 32
      #  error FIXME: this driver only works on 32-bit platforms
      #endif

The point is, the epca driver has a maintainer. Changes to it should go through him.

All the changes you mention can be made in a way that will work on both 32-bit and 64-bit platforms. And they can almost certainly be done without all the ugly IA64 #ifdefs. If you head in that direction, I suspect that the maintainer will be interested in your changes.

Bjorn

#4 lore raw
In reply to Christian Cotte-Barrot
Quoted 17 lines · Bjorn Helgaas
Quoted 9 lines

Agree that all the modifications are not ia64-specific. However, some of them are 64 bits specific and are related to 64 port:
- struct board_chan (digiFep1.h, describes a fragment of I/O memory space shared between driver and firmware) must be of 128 bytes long exactly.
- driver's data definitions and insmod MODULE_PARM declarations must be consistent.
- ioremapped memory base addresses data must be long (64 bits).
- epca module in the kernel sources is not 64 bits

Quoted 4 lines
    epca.c
      #if BITS_PER_LONG != 32
      #  error FIXME: this driver only works on 32-bit platforms
      #endif

The point is, the epca driver has a maintainer. Changes to it should go through him.

Quoted 8 lines

All the changes you mention can be made in a way that will work on both 32-bit and 64-bit platforms. And they can almost certainly be done without all the ugly IA64 #ifdefs. If you head in that direction, I suspect that the maintainer will be interested in your changes.

Bjorn

Thanks Bjorn,

Here are new versions of the epca driver patches. They cancel and replace the previous versions.
- epca-1.50-1_64bit.diff.gz : Digiboard software package patch
- epca-1.50-1_64bit_2.4.19.diff.gz : 2.4.19 kernel tree patch

I had a code review to my modifications and I classified them in three groups. Of course all the ugly IA64 #ifdefs have been deleted. Then
I moved

    __IA64__           to EPCA_64BIT (only related to 64bit port)
    __IA64__           to EPCA_NEW1  (remaining)
    __IA64__DEBUG      to EPCA_DEBUG

__IA64__POLL_DEBUG to EPCA_POLL_DEBUG
I added
FORCE_CONC_DIGI_PACK : force to use concentrator image delivered
with the software package (revision number)

Hope this helps.