public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Sean MacLennan <smaclennan@pikatech.com>
Cc: LinuxPPC-dev <linuxppc-dev@ozlabs.org>, i2c@lm-sensors.org
Subject: Re: [PATCH 2/2] i2c-ibm_iic driver
Date: Sun, 17 Feb 2008 11:52:37 +0100	[thread overview]
Message-ID: <20080217115237.55d9f6d1@hyperion.delvare> (raw)
In-Reply-To: <47B74D76.1000708@pikatech.com>

Hi Sean,

On Sat, 16 Feb 2008 15:54:14 -0500, Sean MacLennan wrote:
> 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.

Just take care of the code you are adding. The old code will go away
soon anyway as I understand it, so don't bother cleaning it up.

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

Yes, I think this is the right time to enforce the index.

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

OK, fine with me then.

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

Note that Frank Edelhaeuser has submitted a driver for this chip
recently:
http://lists.lm-sensors.org/pipermail/lm-sensors/2008-February/022478.html
I didn't have time to review this patch yet, maybe you will want to do
it yourself.

-- 
Jean Delvare

  reply	other threads:[~2008-02-17 10:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-09 17:05 [PATCH] i2c-ibm_iic driver Sean MacLennan
     [not found] ` <4784FED1.2040206-Qtffpm9i2AVWk0Htik3J/w@public.gmane.org>
2008-01-31  4:27   ` Sean MacLennan
     [not found]     ` <47A14E23.50807-Qtffpm9i2AVWk0Htik3J/w@public.gmane.org>
2008-02-14  8:45       ` Jean 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
2008-02-17 10:52               ` Jean Delvare [this message]
2008-02-19  1:42             ` Sean MacLennan
2008-02-19  8:23               ` Jean Delvare
     [not found]                 ` <20080219092321.1fed233d-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-02-19  8:59                   ` Stefan Roese
2008-02-19 22:23                     ` Sean MacLennan
     [not found]                     ` <200802190959.41253.sr-ynQEQJNshbs@public.gmane.org>
2008-02-19 22:55                       ` Arnd Bergmann
     [not found]                         ` <200802192355.17707.arnd-r2nGTMty4D4@public.gmane.org>
2008-02-19 23:18                           ` Sean MacLennan
2008-02-19 23:41                             ` Stephen Rothwell
     [not found]                               ` <20080220104133.e9722e62.sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
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=20080217115237.55d9f6d1@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=i2c@lm-sensors.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=smaclennan@pikatech.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