From: Michael Lawnick <ml.lawnick-Mmb7MZpHnFY@public.gmane.org>
To: Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
Cc: David Daney
<ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>,
linux-mips-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org,
ralf-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org,
rade.bozic.ext-OYasijW0DpE@public.gmane.org
Subject: Re: [PATCH 2/3] I2C: Add driver for Cavium OCTEON I2C ports.
Date: Mon, 25 Jan 2010 12:55:39 +0100 [thread overview]
Message-ID: <4B5D86BB.7040405@gmx.de> (raw)
In-Reply-To: <20100124160017.GF28675-elnMNo+KYs3pIgCt6eIbzw@public.gmane.org>
Hi,
this is the author.
Ben Dooks said the following:
> On Thu, Jan 07, 2010 at 11:54:20AM -0800, David Daney wrote:
<snip>
>> +#ifndef NO_IRQ
>> +#define NO_IRQ (-1)
>> +#endif
>
> this does not fill me with a warm joyous feeling...
see near end of reply.
>
>> +struct octeon_i2c {
>> + wait_queue_head_t queue;
>> + struct i2c_adapter adap;
>> + int irq;
>> + int twsi_freq;
>> + int sys_freq;
>> + uint8_t twsi_ctl;
>> + resource_size_t twsi_phys;
>> + void __iomem *twsi_base;
>> + resource_size_t regsize;
>> + struct device *dev;
>> +};
>
> kerneldoc or any documentation at-all would be nice.
This is driver private data, used within this file only. Usage should be
rather obvious?!
<snip>
>> + do {
>> + data = octeon_i2c_read_sw(i2c, SW_TWSI_EOP_TWSI_STAT);
>> + if (data == STAT_IDLE)
>> + break;
>> + udelay(1);
>> + } while (!time_after(jiffies, orig_jiffies + 2));
>
> you sure you want to busy wait like this?
>
Hmm, yes?
Its a busy wait of typically 10us, but not guaranteed.
Timeout is 1 to 2 jiffies.
Any other suggestion?
<snip>
>> + i2c_data = pdev->dev.platform_data;
>> +
>> + res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + irq = platform_get_irq(pdev, 0);
>> +
>> + if (res_mem == NULL) {
>> + dev_dbg(i2c->dev, "%s: found no memory resource\n", __func__);
>> + kfree(i2c);
>> + return -ENODEV;
>> + }
>> +
>> + if (i2c_data == NULL) {
>> + dev_dbg(i2c->dev, "%s: no I2C frequence data\n", __func__);
>> + kfree(i2c);
>> + return -ENODEV;
>> + }
>
> returning -ENODEV isn't a good idea, the device layer won't print an
> error on seeing -ENODEV as it thinks this is a probe for a device that
> was never there.
>
ACK, couldn't find something really appropriate. Will change to EINVAL.
<snip>
>> + i2c->twsi_phys = res_mem->start;
>> + i2c->regsize = resource_size(res_mem);
>> + i2c->twsi_freq = i2c_data->i2c_freq;
>> + i2c->sys_freq = i2c_data->sys_freq;
>> +
>> + if (!request_mem_region(i2c->twsi_phys, i2c->regsize, res_mem->name)) {
>> + dev_dbg(i2c->dev,
>> + "%s i2c-cavium - request_mem_region failed\n",
>> + __func__);
>> + goto fail_region;
>> + }
>> + i2c->twsi_base = ioremap(i2c->twsi_phys, i2c->regsize);
>> +
>> + init_waitqueue_head(&i2c->queue);
>> +
>> + i2c->irq = irq;
>> + if (i2c->irq != NO_IRQ) {
>
> platform_get_irq() returns a negative error cdoe if no irq is found,
> so you need to do (irq < 0) here otherwise it'll never trip. Should
> also mean yo ucan get rid of NO_IRQ define above.
NO_IRQ is thought of as polling.
The code assumes that request_irq() denies irq < 0
After reviewing kernel code I think this should not be assumed.
I will have to contemplate about this.
<snip>
>> +static struct platform_driver octeon_i2c_driver = {
>> + .probe = octeon_i2c_probe,
>> + .remove = __exit_p(octeon_i2c_remove),
> __devexit_p() here, probably should change __exit to __devexit on the
> remove function.
I thought I had read something about abuse of __devexit (to be used only
for hotplugable devices), but I can't find it anymore.
I'll change.
Currently I'm unsure about using __devinit for probe().
It will be called twice (2 devices), but I can't absolutely tell that
second call will be in system initialization phase.
Your 2 Cents?
>> + .driver = {
>> + .owner = THIS_MODULE,
>> + .name = DRV_NAME,
>> + },
>> +};
>> +
>> +static int __init octeon_i2c_init(void)
>> +{
>> + int rv;
>> +
>> + rv = platform_driver_register(&octeon_i2c_driver);
>> + printk(KERN_INFO "driver %s is loaded\n", DRV_NAME);
>> + return rv;
>> +}
>
> I'd rather not see 'driver loaded' messages if possible.
Whats about adjusting your message filter? ;-)
Would KERN_DEBUG be more appropriate?
We love such messages in our projects. You can filter for the 'loaded
phrases and have an fast overview this way.
--
Kind Regards,
Michael
next prev parent reply other threads:[~2010-01-25 11:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-07 19:50 [PATCH 0/3] Add I2C support for Octeon SOCs David Daney
[not found] ` <4B463B1F.6000404-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2010-01-07 19:54 ` [PATCH 1/3] MIPS: Octeon: Add I2C platform driver David Daney
[not found] ` <1262894061-32613-1-git-send-email-ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2010-01-07 20:35 ` Sergei Shtylyov
[not found] ` <4B4645A3.30401-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
2010-01-07 20:55 ` David Daney
2010-01-07 21:23 ` [PATCH 1/3] MIPS: Octeon: Add I2C platform device David Daney
2010-01-07 19:54 ` [PATCH 2/3] I2C: Add driver for Cavium OCTEON I2C ports David Daney
[not found] ` <1262894061-32613-2-git-send-email-ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2010-01-24 16:00 ` Ben Dooks
[not found] ` <20100124160017.GF28675-elnMNo+KYs3pIgCt6eIbzw@public.gmane.org>
2010-01-25 11:55 ` Michael Lawnick [this message]
2010-01-25 18:19 ` David Daney
2010-01-25 15:12 ` Bozic, Rade (EXT-Other - DE/Ulm)
2010-01-07 19:54 ` [PATCH 3/3] MIPS: Octeon: Register some devices on the I2C bus David Daney
2010-01-07 19:56 ` [PATCH 0/3] Add I2C support for Octeon SOCs David Daney
[not found] ` <4B463C71.3080005-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2010-01-11 14:44 ` Ralf Baechle
[not found] ` <20100111144416.GA23157-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>
2010-01-11 17:16 ` David Daney
[not found] ` <4B4B5CD3.4040204-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2010-01-11 17:23 ` Jean Delvare
2010-01-13 0:49 ` Markus Gothe
[not found] ` <F5F1F5D1-6057-49CF-A5B3-A921E1C0EEEB-SamgB31n2u5IcsJQ0EH25Q@public.gmane.org>
2010-01-13 9:29 ` Jean Delvare
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=4B5D86BB.7040405@gmx.de \
--to=ml.lawnick-mmb7mzphnfy@public.gmane.org \
--cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
--cc=ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org \
--cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mips-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org \
--cc=rade.bozic.ext-OYasijW0DpE@public.gmane.org \
--cc=ralf-6z/3iImG2C8G8FEW9MqTrA@public.gmane.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;
as well as URLs for NNTP newsgroup(s).