[hsflinux] Problem using cnxtinstall.run with Debian Linux For Conexant HSF 56K Data/Fax Modem

[John A. Hart]

Thanks very much.

The patch came through - was this for 2.6.32 or 2.6.26?

JAH

John Albert Hart  |  CIO / Ofc. Mgr.
The Custom Group of Companies
228 East 45th Street, 12th Floor  New York, NY  10017
Ph. 212.818.0300  |  Fx. 212.297.0226
jhart at customstaffing.com   |  www.customstaffing.com
 
Temporary     Consulting     Direct Hire     Executive Search
Office Services  |  Legal |  Accounting and Finance |  Technology  |  Healthcare  |  Payroll
Women-Owned Business Enterprise


-----Original Message-----
From: Chris Vine [mailto:chris at cvine.freeserve.co.uk] 
Sent: Friday, August 12, 2011 5:53 AM
To: P. C. Chan
Cc: John A. Hart; hsflinux at lists.linuxant.com
Subject: Re: [hsflinux] Problem using cnxtinstall.run with Debian Linux For Conexant HSF 56K Data/Fax Modem

On Tue, 9 Aug 2011 14:53:38 -0400
"P. C. Chan" <p_c_chan at hotmail.com> wrote:
> Hi there,
> HSF support has been lacking behind quite a bit.  I am currently 
> running 3.0.1 kernel.  The last time I was able to compile with some 
> hacking was probably a year ago.  :)  Would there be any plan to catch 
> up? If I need to use my HSF modem, I have to boot the system up using 
> an older kernel, like 2.6.32 or something. Regards,P. C.Date:
> Tue, 9 Aug 2011 12:43:13 -0400 From: Jhart at customstaffing.com To:
> hsflinux at lists.linuxant.com Subject: [hsflinux] Problem using
> cnxtinstall.run with Debian Linux For	Conexant HSF 56K
> Data/Fax Modem

Since no one is bothering to deal with this mailing list any more, and the driver no longer works with the kernels of the current version of most mainline distributions, I presume it is now effectively defunct.
It really shows the dangers of relying on proprietary code in linux systems.

I have a patch which I use to compile the hsf driver with the latest kernels, which I attach (I don't know if the mailing list will strip it off, it might).  I do not guarantee it, because none of us see the proprietary code which it interfaces with.  In particular, the file osservices.c uses the global kernel lock for a purpose which is not obvious to me.  I have replaced it with a local lock which may well either not meet the original purpose of using the global lock or may now be completely unnecessary.


Chris