All of lore.kernel.org
 help / color / mirror / Atom feed
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

WARNING: multiple messages have this Message-ID (diff)
From: Michael Lawnick <ml.lawnick@gmx.de>
To: Ben Dooks <ben-linux@fluff.org>
Cc: David Daney <ddaney@caviumnetworks.com>,
	linux-mips@linux-mips.org, ralf@linux-mips.org,
	linux-i2c@vger.kernel.org, khali@linux-fr.org,
	rade.bozic.ext@nsn.com
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@fluff.org.uk>

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

  parent reply	other threads:[~2010-01-25 11:55 UTC|newest]

Thread overview: 32+ 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
2010-01-07 19:50 ` 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
2010-01-07 19:54     ` David Daney
     [not found]     ` <1262894061-32613-1-git-send-email-ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2010-01-07 20:35       ` Sergei Shtylyov
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 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
2010-01-07 19:54     ` David Daney
     [not found]     ` <1262894061-32613-2-git-send-email-ddaney-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2010-01-24 16:00       ` Ben Dooks
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 11:55             ` Michael Lawnick
2010-01-25 18:19           ` David Daney
2010-01-25 18:19             ` David Daney
2010-01-25 15:12         ` Bozic, Rade (EXT-Other - DE/Ulm)
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:54     ` David Daney
2010-01-07 19:56   ` [PATCH 0/3] Add I2C support for Octeon SOCs David Daney
2010-01-07 19:56     ` David Daney
     [not found]     ` <4B463C71.3080005-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2010-01-11 14:44       ` Ralf Baechle
2010-01-11 14:44         ` Ralf Baechle
     [not found]         ` <20100111144416.GA23157-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>
2010-01-11 17:16           ` David Daney
2010-01-11 17:16             ` David Daney
     [not found]             ` <4B4B5CD3.4040204-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2010-01-11 17:23               ` Jean Delvare
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
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 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.