Linux I2C development
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	linux-i2c@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	Phil Reid <preid@electromag.com.au>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	Claudio Foellmi <claudio.foellmi@ergon.ch>
Subject: Re: [PATCH 0/6] i2c: send STOP after recovery; use it for i2c-rcar
Date: Tue, 9 Jan 2018 12:15:50 +0100	[thread overview]
Message-ID: <20180109111550.yaazgjwwzhjq7ogy@ninjato> (raw)
In-Reply-To: <ae01d819-8f12-0f12-fc35-b46fd41c9477@samsung.com>

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]


> I do not feel myself experienced I2C developer, so please be merciful if
> I write stupid things :)

Don't worry :) Thanks for sharing!

> From what I see the whole recovery infrastructure partially duplicates
> i2c_bit_algo/i2c_algo_bit_data algorithm, and GPIO recovery duplicates
> i2c-gpio driver.
> Wouldn't be better to somehow reuse existing code? For example by adding
> recovery callback in i2c_algorithm, and call i2c-gpio::recovery or
> i2c_bit_algo::recovery from rcar-i2c-recovery (in this particular case).

I understand what you mean but I also don't think it is a good idea in
practice. We can't save much by using i2c-gpio, because GPIO is only one
use-case, having custom set/get functions being another one, for
example. A bigger chance for reuse would, in deed, be i2c-algo-bit.c,
but there are some subtle differences and encoding them in the generic
functions would make them more unreadable IMHO. But the real argument
is: dependency hell. The core might be build-in, the rest is a module,
and things get more complicated. And I don't want to enforce this on
_every_ I2C user out there. So, given the really simple functions, I
think it makes sense to have them in the core.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2018-01-09 11:15 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20171204123700epcas2p4273f3313a4c52e7685bbf04d776cbcef@epcas2p4.samsung.com>
2017-12-04 12:36 ` [PATCH 0/6] i2c: send STOP after recovery; use it for i2c-rcar Wolfram Sang
2017-12-04 12:36   ` [PATCH 1/6] i2c: make kerneldoc about bus recovery more precise Wolfram Sang
2017-12-04 12:36   ` [PATCH 2/6] i2c: add identifier in declarations for i2c_bus_recovery Wolfram Sang
2017-12-13 15:23     ` Andy Shevchenko
2018-01-09 11:17       ` Wolfram Sang
2017-12-04 12:36   ` [PATCH 3/6] i2c: add 'set_sda' to bus_recovery_info Wolfram Sang
2017-12-05  1:12     ` Phil Reid
2017-12-05  8:39     ` Linus Walleij
2017-12-05  9:57       ` Phil Reid
2017-12-05 10:32         ` Wolfram Sang
2017-12-05 10:34         ` Linus Walleij
2017-12-05 13:38       ` Wolfram Sang
2017-12-05 15:31         ` Linus Walleij
2017-12-05 16:43           ` Wolfram Sang
2017-12-07 11:25             ` Wolfram Sang
2017-12-10  0:24               ` Linus Walleij
2017-12-13 15:30           ` Andy Shevchenko
2018-01-09 11:23       ` Wolfram Sang
2017-12-13 15:27     ` Andy Shevchenko
2017-12-04 12:36   ` [PATCH 4/6] i2c: ensure SDA is released in recovery if SDA is controllable Wolfram Sang
2017-12-04 12:36   ` [PATCH 5/6] i2c: send STOP after successful bus recovery Wolfram Sang
2017-12-04 12:36   ` [PATCH 6/6] i2c: rcar: implement " Wolfram Sang
2017-12-05  1:13   ` [PATCH 0/6] i2c: send STOP after recovery; use it for i2c-rcar Phil Reid
2017-12-05  9:21   ` Andrzej Hajda
2018-01-09 11:15     ` Wolfram Sang [this message]

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=20180109111550.yaazgjwwzhjq7ogy@ninjato \
    --to=wsa@the-dreams.de \
    --cc=a.hajda@samsung.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=claudio.foellmi@ergon.ch \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=preid@electromag.com.au \
    --cc=wsa+renesas@sang-engineering.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