From: "Paul Schroeder" <paulsch@us.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: "Mike Sullivan" <sullivam@us.ibm.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] ACP Modem (Mwave)
Date: Wed, 11 Jul 2001 17:11:55 -0500 [thread overview]
Message-ID: <OF080C19B9.CE6E4B6A-ON85256A86.00799C20@raleigh.ibm.com> (raw)
The patch has been updated... The updates primarily consist of Alan's
suggested changes below... (thank you) It applies against the 2.4.6
kernel...
It can be gotten here: http://oss.software.ibm.com/acpmodem/
Or directly: http://oss.software.ibm.com/acpmodem/mwave_linux-2.4.6.patch
Comments, questions, suggestions are appreciated...
Cheers...Paul...
---
Paul B Schroeder <paulsch@us.ibm.com>
Software Engineer, Linux Technology Center
IBM Corporation, Austin, TX
Alan Cox <alan@lxorguk.ukuu.org.uk> on 05/16/2001 07:11:34 PM
To: Paul Schroeder/Austin/IBM@IBMUS
cc: linux-kernel@vger.kernel.org, Mike Sullivan/Austin/IBM@IBMUS
Subject: Re: [PATCH] ACP Modem (Mwave)
> Please throw any comments, questions, suggestions, hard objects this
way...
First obvious comments
+ while (uCount-- != 0) {
+ unsigned short val_lo, val_hi;
+ cli();
+ val_lo = InWordDsp(DSP_MsaDataISLow);
+ val_hi = InWordDsp(DSP_MsaDataDSISHigh);
+ put_user(val_lo, pusBuffer++);
+ put_user(val_hi, pusBuffer++);
+ sti();
+
1. Please use spinlocks not cli/sti as they will go away probably in 2.5
2. You can't touch user space holding interrupts off as it can't handle
page faults
+void PaceMsaAccess(unsigned short usDspBaseIO)
+{
+ schedule();
+ udelay(100);
+ schedule();
+}
If you are trying to be friendly then add
if(current->need_resched)
schedule()
just to be more efficient
+BOOLEAN dsp3780I_GetIPCSource(unsigned short usDspBaseIO,
+ unsigned short *pusIPCSourc
s/BOOLEAN/int
s/TRUE/0
s/FALSE/-Eappropriateval
would be more in keeping. Not a bug by any means
The ioctl locking seems wrong. It doesnt look like the DSP accesses are
locked against one another and you can issue multiple ioctls in parallel in
different threads
If mwave_read/write do nothing then they should really be returning an
error
code. 0 is EOF, count on write is success.
+BOOLEAN smapi_init()
you want (void) or you get compiler warnings on some compiler revisions
+ PRINTK_1(TRACE_SMAPI, "smapi::smapi_init entry\n");
+
+ usSmapiID = CMOS_READ(0x7C);
+ usSmapiID |= (CMOS_READ(0x7D) << 8);
CMOS reads/writes must be done holding the lock against other cmos users
+int Initialize(THINKPAD_BD_DATA * pBDData)
Please dont have globals with names so generic
Hope those are useful
Alan
next reply other threads:[~2001-07-11 22:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-11 22:11 Paul Schroeder [this message]
2001-07-12 19:55 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2001-07-18 16:02 Paul Schroeder
2001-07-18 16:31 ` paulsch
2001-07-18 17:22 ` Thomas Hood
2001-07-18 19:02 ` Robert Love
2001-05-16 20:40 Paul Schroeder
2001-05-17 0:11 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=OF080C19B9.CE6E4B6A-ON85256A86.00799C20@raleigh.ibm.com \
--to=paulsch@us.ibm.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=sullivam@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®