| Summary: | DAHLIN-00223: [Patch] Add support for Rhino Hardware | ||
| Reporter: | James Finstrom (jfinstrom) | Labels: | |
| Date Opened: | 2010-11-02 12:08:54 | Date Closed: | 2019-05-31 09:43:55 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | NewFeature |
| Versions: | 2.4.0 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ( 0) Rhino-kmods.patch | |
| Description: | Add the modules required to support Rhino Hardware. rcbfx.ko - Supports all variants of Rhino Analog cards except the old r4fxo r1t1.ko - Supports all variants of R1T1 Single span T1/E1/J1 cards rxt1.ko - Supportd all variants of R2T1 and R4T1 multi-span T1/E1/J1 cards. All Binary firmwares have been stripped and are not required at compile or runtime. ****** ADDITIONAL INFORMATION ****** Currently drivers build against the DAHDI sources outside of the tree. This works well on source built systems but requires extra work and some hacking on package based systems. Inclusion in the tree allows for a more uniform end user environment. | ||
| Comments: | By: James Finstrom (jfinstrom) 2010-11-02 14:18:27 The patch as it sits is very chatty as pointed out by sruffell, I will make some adjustments and re-upload By: Tzafrir Cohen (tzafrir) 2010-11-08 05:58:37.000-0600 Good to see the drivers submitted :-) I suspect that the ReviewBoard will be a better tool to handle a large "patch" (extra code). See https://reviewboard.asterisk.org/r/977/ for some a quick checklist. (The code ATM has many of those minor styling issues, such as "line over 80 characters" and "do not use C99 // comments") Also, can you please explain what is include/dahdi/rcbfx_ioctl.h intended for? Can you provide a test program for it to be included in dahdi-tools? By: Shaun Ruffell (sruffell) 2010-11-08 06:47:12.000-0600 Just my 2 cents... Many (not all) of those errors comes from the fact that the drivers contains the GpakApi for their hardware echocan. Those same types of errors currently exist in the tree in the drivers/dahdi/voicebus/gpakApi.c file as well. While the format of that module is on my list of things to change as part of being merge-ready, keeping it in it's present form simplifies the process of consuming updates from the third-party who provides that code. So...while I hope it's updated (and I hope I soon get the opportunity to update the GpakApi source that is already in the dahdi-linux source) I personally can understand the rationale if that doesn't happen before it's merged. Much the same way the oct612x external was added in tree without fixing the formatting problems.... | ||