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 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).