linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Sean MacLennan <smaclennan@pikatech.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: LinuxPPC-dev <linuxppc-dev@ozlabs.org>, i2c@lm-sensors.org
Subject: Re: [PATCH 2/2] i2c-ibm_iic driver
Date: Sat, 16 Feb 2008 15:54:14 -0500	[thread overview]
Message-ID: <47B74D76.1000708@pikatech.com> (raw)
In-Reply-To: <20080216103123.50a0128b@hyperion.delvare>

Jean Delvare wrote:
> Hi Sean,
>
> On Fri, 15 Feb 2008 23:11:12 -0500, Sean MacLennan wrote:
>   
>> Here is the of platform patch. I removed the retries and removed the spaces used for spacing.
>>
>> Cheers,
>>    Sean
>>
>> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
>>     
>
> First of all: please run scripts/checkpatch.pl on your patch and fix
> the reported errors. It tells me:
>   total: 10 errors, 5 warnings, 222 lines checked
> which is definitely too much.
>   
Many of the errors/warnings are from the cut and paste of the original 
code. I realize this doesn't justify my new code, but does beg the 
question; should I also cleanup the original code? And how much? I am 
tempted to cleanup all but the #ifdef CONFIG_IBM_OCP part.

A few comments, everything else I agree with.

>> +		return -ENOMEM;
>> +	}
>> +
>> +	/* This assumes we don't mix index and non-index entries. */
>> +	indexp = of_get_property(np, "index", NULL);
>> +	dev->idx = indexp ? *indexp : index++;
>>     
>
> I don't like this static index thing much. Can't you just make the
> "index" OF property mandatory? Mixing ways to number things can become
> very confusing. In particular as you are using dev->idx later to call
> i2c_add_numbered_adapter(), the caller is really supposed to know what
> they are doing with the bus numbers.
>   
I also don't really like mixing the two methods, hence the comment. I 
did this so existing dts files, which don't currently have an index, 
would work as is. Maybe it would be better to add the index?

Without my patch, or one like it, you cannot currently use the IBM IIC 
in the arch/powerpc branch, so maybe now *is* the time to enforce an index?

So if nobody responds with a good reason not to, I will change the code 
to require the index to be set. Less testing for me ;)
>> +	adap->timeout = 1;
>> +	adap->nr = dev->idx;
>>     
>
> Looks to me like the block above has much in common with the original
> probe function, maybe it would be worth sharing the code to make future
> maintenance easier?
>   
It is my understanding the the arch/ppc branch is going away in the 
middle of the year. So I kept the of platform code separate and clean 
expecting the CONFIG_IBM_OCP block to be removed in the near future. So 
future maintenance should not be an issue.
> Note that I cannot test the code so I am relying on the linuxppc-dev
> folks to test it
I can test the of platform code and the common code. I am not setup to 
test the OCP code, which is why I am loath to change it. I use the IBM 
IIC for access to an  ad7414 thermal chip (currently not in the kernel, 
I am working on that too) and for reading an eeprom.

Cheers,
   Sean

  reply	other threads:[~2008-02-16 20:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-09 17:05 [PATCH] i2c-ibm_iic driver Sean MacLennan
     [not found] ` <47A14E23.50807@pikatech.com>
     [not found]   ` <20080214094516.1b958ae4@hyperion.delvare>
2008-02-16  4:07     ` [PATCH 1/2] " Sean MacLennan
2008-02-16  8:20       ` Jean Delvare
2008-02-16  4:11     ` [PATCH 2/2] " Sean MacLennan
2008-02-16  9:31       ` Jean Delvare
2008-02-16 20:54         ` Sean MacLennan [this message]
2008-02-17 10:52           ` Jean Delvare
2008-02-19  1:42         ` Sean MacLennan
2008-02-19  8:23           ` Jean Delvare
2008-02-19  8:59             ` Stefan Roese
2008-02-19 22:23               ` Sean MacLennan
2008-02-19 22:55               ` Arnd Bergmann
2008-02-19 23:18                 ` Sean MacLennan
2008-02-19 23:41                   ` Stephen Rothwell
2008-02-19 23:54                     ` Arnd Bergmann
2008-02-20  6:57                 ` Jean Delvare
2008-02-19 21:58             ` Sean MacLennan
2008-02-20  7:20               ` 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=47B74D76.1000708@pikatech.com \
    --to=smaclennan@pikatech.com \
    --cc=i2c@lm-sensors.org \
    --cc=khali@linux-fr.org \
    --cc=linuxppc-dev@ozlabs.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).