Conexant HCF 56k PCI modem help

Gary Corcoran garycor at
Sat Jan 24 22:26:56 PST 2004


> 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.

I can't help you directly with your problem, but perhaps a clarification
might help you or someone else understand the problem better.  If the modem
you have is "controllerless", then it *IS* a "winmodem".  It needs a "windows"
(or equivalent) driver to emulate the missing controller.  If it's both
controllerless *and* DSP-less, then it's a "softmodem".  That is, a softmodem
is one that does *everything* (except the actual Analog-to-Digital and Digital
-to-Analog conversions) in software.  So a softmodem needs realtime Digital
Signal Processing code (as well as the controller emulation code) that runs
on your host CPU.


> Under a vanilla 5.2-RELEASE, pciconf showed:
> none9 at 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:
> 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
> 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

More information about the freebsd-hardware mailing list