From: Grosjean Stephane <s.grosjean@peak-system.com>
To: Wolfgang Grandegger <wg@grandegger.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 18:10:18 +0100 [thread overview]
Message-ID: <4F0DC27A.70202@peak-system.com> (raw)
In-Reply-To: <4F0C4020.8010304@grandegger.com>
Hi Wolfgang,
Le 10/01/2012 14:41, Wolfgang Grandegger a écrit :
> Hi Stephane,
>
> please send a patch using a proper subject line and commit message. Also
> add a CC to the pcmcia linux mailing list. Thanks.
Ok I'll do that for v2.
> +
> +/* PEAK-System PCMCIA driver name */
> +#define DRV_NAME "peak_pccard"
> I find the mix of "peak_pcmcia" and "peak_pccard" and "pcan_pccard" for
> the same hardware confusing. Please use just one name and prefix.
Ok, decision was made: peak_pcmcia, once for all!
Closed.
>> +
>> +/* PEAK-System PCMCIA driver version */
>> +#define DRV_VERSION_MAJOR 0
>> +#define DRV_VERSION_MINOR 2
>> +#define DRV_VERSION_SUBMINOR 0
>> +
>> +#define DRV_VERSION_STRING __stringify(DRV_VERSION_MAJOR)"."\
>> + __stringify(DRV_VERSION_MINOR)"."\
>> + __stringify(DRV_VERSION_SUBMINOR)
> As for the USB driver, I would remove this redundant versioning stuff.
> Also version 0.2.0 does not really sound like like a stable piece of
> software.
Removed from both drivers.
Closed.
> +
> +#define DRV_CHAN_MAX 2
> +
> +#define DRV_CAN_CLOCK (16000000 / 2)
> Hm, the prefix DRV_ here and below does not really make sense. But well,
> it's a minor issue.
PCC_
Closed.
>> +static int pcan_write_eeprom(struct pcan_pccard *card, u16 addr, u8 v)
>> +{
>> + u8 status;
>> + int err, i;
>> +
>> + /* write instruction */
>> + pcan_write_reg(card, DRV_SPI_INR, 0x06);
> Macro definitons would be nice.
TODO
>> + /* 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 */
> +
> +write_eeprom_err:
> + dev_info(&card->dev->dev,
> + "writing 0x%x in eeprom @0x%x failed (err %d)\n",
> + v, addr, err);
> Info or error. Can this happen? If yes, how often?
It's an error and I never saw it. Moreover, writing in eeprom is (only)
done to power up/down the can connectors (so first when driver is
loaded, second when it is unloaded).
Moved the dev_info() into dev_err().
>> + return err;
>> +}
>> +
>> +/*
>> + * control the leds
>> + * @led_mask: should be an or made of DRV_LED(x)
>> + * @state: DRV_LED_ON, DRV_LED_OFF, DRV_LED_SLOW or DRV_LED_FAST
>> + */
> Please remove the docbook tags.
Ok.
>> +/*
>> + * 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++) {
>> + 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?
>> +
>> + dev_info(&dev->dev, "new PEAK-System pcmcia card detected:\n");
>> +
>> + dev_info(&dev->dev, "%s %s\n",
>> + dev->prod_id[0] ? dev->prod_id[0] : "PEAK-System",
>> + dev->prod_id[1] ? dev->prod_id[1] : "PCAN-PC Card");
> One line (dev_info) should be enough. Also "dev->dev" is not really
> readable. "dev->p[cmcia_]dev" would be much better.
Since this is the 2nd time this request comes, considering its priority
as increased: thus, changed into a single dev_info();
dev changed into pdev: Ok.
>> + 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.
>> +
>> + /* sja1000 api uses iomem */
>> + card->ioport_addr = ioport_map(dev->resource[0]->start,
>> + resource_size(dev->resource[0]));
>> + if (!card->ioport_addr) {
>> + err = -ENOMEM;
>> + goto probe_err_3;
>> + }
>> +
>> + /* display firware version */
>> + dev_info(&dev->dev, "firmware %d.%d\n",
>> + pcan_read_reg(card, DRV_FW_MAJOR),
>> + pcan_read_reg(card, DRV_FW_MINOR));
>> +
>> + /* detect available channels */
>> + pcan_add_channels(card);
>> + if (!card->chan_count)
>> + goto probe_err_3;
>> +
>> + /* init the timer which controls the leds */
>> + init_timer(&card->led_timer);
>> + card->led_timer.function = pcan_led_timer;
>> + card->led_timer.data = (unsigned long)card;
>> +
>> + /* request the given irq */
>> + err = request_irq(dev->irq,&pcan_isr, IRQF_SHARED, DRV_NAME, card);
>> + if (err)
>> + goto probe_err_4;
>> +
>> + /* power on the connectors */
>> + pcan_set_can_power(card, 1);
>> +
>> + return 0;
>> +
>> +probe_err_4:
>> + /* unregister can devices from network */
>> + pcan_free_channels(card);
>> +
>> +probe_err_3:
>> + kfree(card);
>> + dev->priv = NULL;
>> +
>> +probe_err_2:
>> + pcmcia_disable_device(dev);
>> +
>> +probe_err_1:
>> + return err;
> I'm missing ioport_unmap()!
Yes you're perfectly right: in many cases, it will be right called by
pcan_free_channels() but not before going to "probe_err_3", when no
channel are detected. So changed code above into:
/* detect available channels */
pcan_add_channels(card);
if (!card->chan_count) {
ioport_unmap(card->ioport_addr);
goto probe_err_3;
}
> Thanks for your contribution.
>
> Wolfgang.
You're welcome, thanks for your time.
Stéphane
next prev parent reply other threads:[~2012-01-11 17:10 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 [this message]
2012-01-11 18:35 ` Wolfgang Grandegger
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=4F0DC27A.70202@peak-system.com \
--to=s.grosjean@peak-system.com \
--cc=linux-can@vger.kernel.org \
--cc=socketcan@hartkopp.net \
--cc=wg@grandegger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.