linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wolfgang Grandegger <wg@grandegger.com>
To: s.grosjean@peak-system.com
Cc: Oliver Hartkopp <socketcan@hartkopp.net>,
	linux-can Mailing List <linux-can@vger.kernel.org>
Subject: Re: Add support for PEAK PCMCIA PCAN-PC card
Date: Wed, 11 Jan 2012 19:35:49 +0100	[thread overview]
Message-ID: <4F0DD685.9070002@grandegger.com> (raw)
In-Reply-To: <4F0DC27A.70202@peak-system.com>

Hi Stephane,

On 01/11/2012 06:10 PM, Grosjean Stephane wrote:
> Hi Wolfgang,

>>> +    /* wait until write enable */
>>> +    for (i = 0; i<  DRV_WRITE_MAX_LOOP; i++) {
>>> +        /* RDSR */
>> This comment does not tell me anything.
> 
> Ok, what about these one?
> 
> /* write command reading the status register */
> ...
> /* get the status register and check write enable bit */
> 
> then;
> 
> /* write command reading the status register */
> ...
> /* get the status register and check write in progress bit */

I don't know what RDSR means, sorry. Just put something human readable.
With some meaningful macro definitions the comment might even be
obsolete/redundant.

..

>>> +/*
>>> + * interrupt service routine
>>> + */
>>> +static irqreturn_t pcan_isr(int irq, void *dev_id)
>>> +{
>>> +    struct pcan_pccard *card = dev_id;
>>> +    struct net_device *netdev;
>>> +    irqreturn_t retval = IRQ_NONE;
>>> +    int i, again;
>>> +
>>> +    do {
>>> +        again = 0;
>>> +
>>> +        /* Check interrupt for each channel */
>>> +        for (i = 0; i<  card->chan_count; i++) {

s/i</i </

>>> +            netdev = card->channel[i].netdev;
>>> +            if (!netdev)
>>> +                continue;
>>> +
>>> +            if (sja1000_interrupt(irq, netdev) == IRQ_HANDLED)
>>> +                again = 1;
>>> +        }
>>> +
>>> +        /* At least one channel handled the interrupt */
>>> +        if (again)
>>> +            retval = IRQ_HANDLED;
>>> +
>>> +    } while (again);
>> I wonder if it makes sense to limit the loop count.
> 
> Had a look to sja1000_interrupt(): you're right, could enter in an
> infinite loop if one of the sja1000 failed into always sending interrupt
> signals...
> On my side, I wonder why entering such a do { } while (again) loop?

Is it an edge or level sensitive interrupt? This custom interrupt
handling was introduced to handle hardware which does not allow to
handle the interrupt per device and the loop is required to avoid
interrupt losses, IIRC. The corresponding PEAK PCAN driver has a similar
for loop:

        loop_count = 0; // restart, since all channels must respond in
                           one pass with no interrupt pending

>>> +    card = kzalloc(sizeof(struct pcan_pccard), GFP_KERNEL);
>>> +    if (!card) {
>>> +        dev_err(&dev->dev, "kzalloc() failure\n");
>> Please be more specific, e.g.: "couldn't allocated card memory".
> 
> As you want, you're (one of) the chief(s) ;-)
> Closed.

Well, the messages should make sense for the user of that driver, and
not for the developer.

Wolfgang

      reply	other threads:[~2012-01-11 18:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-09 14:51 Add support for PEAK PCMCIA PCAN-PC card Stephane Grosjean
2012-01-09 23:23 ` Marc Kleine-Budde
2012-01-11 15:13   ` Grosjean Stephane
2012-01-10 13:41 ` Wolfgang Grandegger
2012-01-10 15:05   ` Oliver Hartkopp
2012-01-11 14:11     ` Grosjean Stephane
2012-01-11 14:43       ` Wolfgang Grandegger
2012-01-11 15:00       ` Oliver Hartkopp
2012-01-11 15:11         ` Wolfgang Grandegger
2012-01-11 17:10   ` Grosjean Stephane
2012-01-11 18:35     ` Wolfgang Grandegger [this message]

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=4F0DD685.9070002@grandegger.com \
    --to=wg@grandegger.com \
    --cc=linux-can@vger.kernel.org \
    --cc=s.grosjean@peak-system.com \
    --cc=socketcan@hartkopp.net \
    /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;
as well as URLs for NNTP newsgroup(s).