From owner-freebsd-hardware@FreeBSD.ORG Sat Jan 24 20:47:15 2004 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 793DB16A4CE for ; Sat, 24 Jan 2004 20:47:15 -0800 (PST) Received: from kiwi-computer.com (megan.kiwi-computer.com [63.224.10.3]) by mx1.FreeBSD.org (Postfix) with SMTP id EF26943D41 for ; Sat, 24 Jan 2004 20:47:13 -0800 (PST) (envelope-from rick@kiwi-computer.com) Received: (qmail 21068 invoked by uid 2001); 25 Jan 2004 04:47:12 -0000 Date: Sat, 24 Jan 2004 22:47:12 -0600 From: "Rick C. Petty" To: freebsd-hardware@freebsd.org Message-ID: <20040125044712.GA20903@megan.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Conexant HCF 56k PCI modem help X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 04:47:15 -0000 For a project, our customer wants to use these 56k PCI modems from Creative. Although not my first choice, I did some research and discovered that the modems use a Conexant Systems, Inc. (vendor id 0x14F1) SmartHCF 56k chip (device id 0x1059). It is not a "winmodem"; the HCF family is "Controllerless" vs. the HSF "software" chipsets. Under a vanilla 5.2-RELEASE, pciconf showed: none9@pci1:7:0: class=0x078000 card=0x1059 chip=0x105914F1 rev=0x08 hdr=0x00 vendor = 'Conexant Systems, Inc.' device = 'HCF 56k Data/Fax/Voice Modem (Worldwide)' class = simple comms I started by adding the following entry to the top of src/dev/puc/pucdata.c: { "HCF 56k Data/Fax/Voice Modem (Worldwide)", NULL, { 0x14F1, 0x1059, 0x148D, 0x1059 }, { 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF }, { { PUC_PORT_TYPE_UART, 0x10, 0x00, 0, 0 }, }, }, and the kernel detected the device (puc0) an bootup, but was unable to attach because it "could not get resource". That last line in the struct was pure guesswork, based on many other entries. I tried it with PUC_PORT_TYPE_COM and had the same error. Digging through puc.c I tried adding PUC_FLAGS_ALTRES to the flags and it found the device, although sometimes would hang on boot [I guessed various numbers for the "bar" parameter with varying levels of bootability], so I tried another approach.. Further internet investigation revealed a linux driver from linuxant: http://www.linuxant.com/drivers/hcf/downloads-license.php They provide two versions of their drivers-- one binary-only "full" version (at a "modest price") and a free (limited) version with source code. The code generates a few [linux] kernel modules via some shims to access the binary-only modules. I am hoping someone else of more kernel/driver/puc(4) experience has the time to help get this ported... please let me know ASAP. Alternatively, if someone could suggest a better solution (PCI-only) for not much more than US$25/ea. that works well in FreeBSD 5.x I would be quite grateful! Thanks in advance, -- Rick C. Petty Senior Software Engineer KIWI Computer