public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V5] ARM: OMAP: I2C:  New read, write and probe functions
Date: Mon, 03 Jun 2013 07:13:43 +0200	[thread overview]
Message-ID: <51AC2607.3000209@denx.de> (raw)
In-Reply-To: <b86865dc92ed31d2d2383c832a356e28.squirrel@www.mm-sol.com>

Hello Lubomir,

Am 02.06.2013 13:42, schrieb Lubomir Popov:
>> Hello Lubomir,
>>
>> Am 01.06.2013 18:44, schrieb Lubomir Popov:
>>> New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4
>>> (4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older
>>> OMAPs and derivatives as well. The only anticipated exception would
>>> be the OMAP2420, which shall require driver modification.
[...]
>>>  drivers/i2c/omap24xx_i2c.c | 490 +++++++++++++++++++++++++++------------------
>>>  1 file changed, 299 insertions(+), 191 deletions(-)
>>
>> Tested on 3 arm335x based boards, which one uses i2c in SPL
>> code for getting ram parameters, so:
>>
>> Tested-by: Heiko Schocher <hs@denx.de>
> Many thanks for testing, to Tom as well (he did it on the
> Beagleboards, but for one of the older versions, V3 I believe,
> right?).
> When it comes to versions, I see that V1 and V2 are still listed
> in patchwork, probably because of slightly different wording of
> the subject:
> http://patchwork.ozlabs.org/patch/233823/
> http://patchwork.ozlabs.org/patch/246204/
> Could you or Tom clean this up, please? Thanks.

Cleared the v3 v4 version, but missed the v2 and v1, Done.

>> Just one comment:
>> Your patch has 9 checkpatch warnings which are all lines
>> (printf strings) over 80 chars ... some with lines > 110
>> characters ... I know, tom gave you a OK for this ... I am
>> also unhappy with splitting a printf-string over 2 or more lines ...
>> but we have this 80 characters rule ... Wolfgang, what do you
>> think? Should we loosen this rule for printf-strings?
> Yes, I had the long strings splitted in the older versions, but
> then unrolled them back as per Tom's recommendation. IMHO, grep-ability
> is worth breaking this particular rule... But perhaps only for pure

Yep.

> strings w/o format placeholders? I mean, strings could be splitted
> at the format parameters of printf/sprintf arguments.

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

  reply	other threads:[~2013-06-03  5:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-01 16:44 [U-Boot] [PATCH V5] ARM: OMAP: I2C: New read, write and probe functions Lubomir Popov
2013-06-02  5:20 ` Heiko Schocher
2013-06-02 11:42   ` Lubomir Popov
2013-06-03  5:13     ` Heiko Schocher [this message]
2013-06-04  4:26       ` Heiko Schocher
2013-06-04  6:49         ` Lubomir Popov
2013-06-04  7:03           ` Heiko Schocher
2013-06-04 21:38             ` Tom Rini
2013-06-02 13:08   ` Tom Rini
2013-06-03  5:15     ` Heiko Schocher

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=51AC2607.3000209@denx.de \
    --to=hs@denx.de \
    --cc=u-boot@lists.denx.de \
    /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