Linux-i2c Archive on lore.kernel.org
 help / color / Atom feed
From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
To: Wolfram Sang <wsa@kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"jdelvare@suse.com" <jdelvare@suse.com>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 6/6] i2c: mpc: Interrupt driven transfer
Date: Sun, 11 Apr 2021 21:31:47 +0000
Message-ID: <723acaa7-ff57-40c2-a733-a520c5899800@alliedtelesis.co.nz> (raw)
In-Reply-To: <20210410201302.GC2471@kunai>


On 11/04/21 8:13 am, Wolfram Sang wrote:
> On Mon, Mar 29, 2021 at 02:52:06PM +1300, Chris Packham wrote:
>> The fsl-i2c controller will generate an interrupt after every byte
>> transferred. Make use of this interrupt to drive a state machine which
>> allows the next part of a transfer to happen as soon as the interrupt is
>> received. This is particularly helpful with SMBUS devices like the LM81
>> which will timeout if we take too long between bytes in a transfer.
>>
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> Okay, this change is too large and HW specific for a detailed review.
> But I trust you and hope you will be around to fix regressions if I
> apply it for 5.13?
Yep I plan on being around. I've got access to a couple of designs with 
P2040 and T2081 so hopefully that's sufficient to deal with any 
regressions. One issue is a lack of different i2c devices (the systems 
we have tend to use the same devices) but hopefully any reports of 
regression will be from people with access to such devices.
> That kind of leads to the question if you want to
> step up as the maintainer for this driver?
Sure can do. It'd be nice if it was someone from NXP but I think they've 
lost interest in the PowerPC based SoCs. Should I send a patch for 
MAINTAINERS? If so does that go through the i2c tree?
> Only thing I noticed was a "BUG" and "BUG_ON" and wonder if we really
> need to halt the kernel in that case. Maybe WARN is enough?

Yeah I think they can both be WARN variants. The one in mpc_xfer() can 
happily continue. It's a little less clear what I should do in 
mpc_i2c_do_action() if the WARN is ever hit but in theory it should be 
an unreachable case anyway so the only thing that could get there is 
some kind of memory corruption which would likely cause a crash elsewhere.

Do you want me to send a V3 of just that patch?

> I'll apply the first five patches now, they look good to me.
>

  reply index

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-29  1:52 [PATCH v2 0/6] i2c: mpc: Refactor to improve responsiveness Chris Packham
2021-03-29  1:52 ` [PATCH v2 1/6] dt-bindings: i2c-mpc: Document interrupt property as required Chris Packham
2021-03-30 15:13   ` Rob Herring
2021-03-29  1:52 ` [PATCH v2 2/6] dt-bindings: i2c: convert i2c-mpc to json-schema Chris Packham
2021-03-30 15:18   ` Rob Herring
2021-03-29  1:52 ` [PATCH v2 3/6] i2c: mpc: Make use of i2c_recover_bus() Chris Packham
2021-03-29  1:52 ` [PATCH v2 4/6] i2c: mpc: make interrupt mandatory and remove polling code Chris Packham
2021-04-10 20:16   ` Wolfram Sang
2021-04-11 23:57     ` Chris Packham
2021-03-29  1:52 ` [PATCH v2 5/6] i2c: mpc: use device managed APIs Chris Packham
2021-04-12 22:52   ` Andy Shevchenko
2021-04-12 22:55     ` Andy Shevchenko
2021-04-12 23:21     ` Chris Packham
2021-04-12 23:26       ` Chris Packham
2021-04-12 23:34       ` Andy Shevchenko
2021-03-29  1:52 ` [PATCH v2 6/6] i2c: mpc: Interrupt driven transfer Chris Packham
2021-04-10 20:13   ` Wolfram Sang
2021-04-11 21:31     ` Chris Packham [this message]
2021-04-12 18:17       ` Wolfram Sang
2021-04-12 22:57     ` Andy Shevchenko

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=723acaa7-ff57-40c2-a733-a520c5899800@alliedtelesis.co.nz \
    --to=chris.packham@alliedtelesis.co.nz \
    --cc=devicetree@vger.kernel.org \
    --cc=jdelvare@suse.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=robh+dt@kernel.org \
    --cc=wsa@kernel.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

Linux-i2c Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-i2c/0 linux-i2c/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-i2c linux-i2c/ https://lore.kernel.org/linux-i2c \
		linux-i2c@vger.kernel.org
	public-inbox-index linux-i2c

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-i2c


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git