mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nish Aravamudan <nish.aravamudan@gmail.com>
To: Chase Venters <chase.venters@clientec.com>
Cc: Harald Welte <laforge@gnumonks.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] New: Omnikey CardMan 4040 PCMCIA Driver
Date: Sat, 3 Sep 2005 15:13:43 -0700	[thread overview]
Message-ID: <29495f1d0509031513232b11b1@mail.gmail.com> (raw)
In-Reply-To: <200509031627.00947.chase.venters@clientec.com>

On 9/3/05, Chase Venters <chase.venters@clientec.com> wrote:
> > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> > Smartcard Reader.
> 
> Someone correct me if I'm wrong, but wouldn't these #defines be a problem 
> with the new HZ flexibility:
> 
> #define CCID_DRIVER_BULK_DEFAULT_TIMEOUT        (150*HZ)
> #define CCID_DRIVER_ASYNC_POWERUP_TIMEOUT       (35*HZ)
> #define CCID_DRIVER_MINIMUM_TIMEOUT             (3*HZ)
> #define READ_WRITE_BUFFER_SIZE 512
> #define POLL_LOOP_COUNT                         1000

These are all fine. Although I am a bit suspicious of 150 second
timeouts; but if that is the hardware...

> /* how often to poll for fifo status change */
> #define POLL_PERIOD                             (HZ/100)

This needs to be msecs_to_jiffies(10), please.

> In particular, 2.6.13 allows a HZ of 100, which would define POLL_PERIOD to 0.

Um, 100/100 = 1, not 0?

> Your later calls to mod_timer would be setting cmx_poll_timer to the current
> value of jiffies.

Which is technically ok, because HZ=100, a
     jiffies + 0
or
     jiffies + 1
timeout request will both result in the soft-timer being expired at
the *next* timer interrupt. Regardless, you're right, and
msecs_to_jiffies() will cover it.

> Also, you've got a typo in the comments:
> 
> *       - adhere to linux kenrel coding style and policies
> 
> Forgive me if I'm way off - I'm just now getting my feet wet in kernel
> development. Just making comments based on what I (think) I know at this
> point.

Of bigger concern to me is the use of the sleep_on() family of
functions, all of which are deprecated.

Thanks,
Nish

  reply	other threads:[~2005-09-03 22:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-04 10:12 Harald Welte
2005-09-03 21:27 ` Chase Venters
2005-09-03 22:13   ` Nish Aravamudan [this message]
2005-09-03 22:23     ` Chase Venters
2005-09-04  7:33     ` Harald Welte
2005-09-04 11:20   ` Harald Welte
2005-09-06 16:15     ` Roland Dreier
2005-09-06 17:11       ` Harald Welte
2005-09-03 21:56 ` Alexey Dobriyan
2005-09-04  7:10   ` Harald Welte
2005-09-04 11:08 ` Harald Welte
2005-09-03 22:27   ` Jesper Juhl
2005-09-04 21:06     ` Horst von Brand
2005-09-04 22:10       ` Jesper Juhl
2005-09-05 10:30     ` Harald Welte
2005-09-04 12:58 ` Ingo Oeser
2005-09-05  9:14   ` Harald Welte

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=29495f1d0509031513232b11b1@mail.gmail.com \
    --to=nish.aravamudan@gmail.com \
    --cc=chase.venters@clientec.com \
    --cc=laforge@gnumonks.org \
    --cc=linux-kernel@vger.kernel.org \
    /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

Powered by JetHome