linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Wolfram Sang <wsa@kernel.org>,
	linux-i2c <linux-i2c@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/4] i2c: mpc: Interrupt driven transfer
Date: Tue, 13 Apr 2021 23:23:45 +0000	[thread overview]
Message-ID: <e12dea50-5fae-c31c-46e6-572488ca9ca1@alliedtelesis.co.nz> (raw)
In-Reply-To: <09f636b8-c126-af14-fbc3-9d6becb15df5@alliedtelesis.co.nz>


On 14/04/21 10:28 am, Chris Packham wrote:
>
> On 14/04/21 1:52 am, Andy Shevchenko wrote:
>> On Tue, Apr 13, 2021 at 8:10 AM Chris Packham
>> <chris.packham@alliedtelesis.co.nz> 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.
>> Also see my other comments below.
>>
>> ...
>>
...
>>
>>> +               dev_dbg(i2c->dev, "%s: %s %02x\n", __func__,
>>> +                       action_str[i2c->action], byte);
>> You already printed action. Anything changed?
> It's mainly the addition of the byte read. I couldn't figure out a 
> sensible way of always printing the action then appending the data in 
> the read/write case. Open to suggestions.
>>
>>> +               dev_dbg(i2c->dev, "%s: %s %02x\n", __func__,
>>> +                       action_str[i2c->action], 
>>> msg->buf[i2c->byte_posn]);
>> Deduplicate this. Perhaps at the end of switch-case print once with
>> whatever temporary variable value you want to.
>>
>> ...
> I thought about this but decided not to because in the write case it's 
> printed before going to hardware and in the read case it's after. If I 
> moved it after the case I'd have to use something other than 
> i2c->byte_posn which seemed error prone.
I looked at a few options for this. Avoiding repeating the action is 
doable but I feel it needs to be replaced by something otherwise it's 
just a random byte value in the output (e.g. "buf = "/"byte = "). 
Rolling everything into a single line of output seems really hard to do 
to cover all the possible actions.

Completely deduplicating this means I need to add code to store the 
action before the case and check it afterward which will run all the 
time. This seems overkill for the sake of avoiding duplicate code which 
is usually compiled out.

I'm erring on the side of just removing __func__ and leaving the rest 
as-is. Unless you feel really strongly that something else should be done.

One option not mentioned is to remove these two debug statements. I'd be 
OK with that.


  reply	other threads:[~2021-04-13 23:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-13  5:09 [PATCH v3 0/4] i2c: mpc: Refactor to improve responsiveness Chris Packham
2021-04-13  5:09 ` [PATCH v3 1/4] i2c: mpc: use device managed APIs Chris Packham
2021-04-13 12:21   ` Wolfram Sang
2021-04-13 13:31     ` Andy Shevchenko
2021-04-13 13:31       ` Andy Shevchenko
2021-04-13  5:09 ` [PATCH v3 2/4] i2c: mpc: Interrupt driven transfer Chris Packham
2021-04-13 12:22   ` Wolfram Sang
2021-04-13 13:52   ` Andy Shevchenko
2021-04-13 22:28     ` Chris Packham
2021-04-13 23:23       ` Chris Packham [this message]
2021-04-13  5:09 ` [PATCH v3 3/4] i2c: mpc: Remove redundant NULL check Chris Packham
2021-04-13 12:27   ` Wolfram Sang
2021-04-13  5:09 ` [PATCH v3 3/3] MAINTAINERS: Add Chris Packham as FREESCALE MPC I2C maintainer Chris Packham
2021-04-13  5:14   ` Chris Packham
2021-04-13 11:19     ` Andy Shevchenko
2021-04-13  5:09 ` [PATCH v3 4/4] " Chris Packham
2021-04-13 12:27   ` Wolfram Sang

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=e12dea50-5fae-c31c-46e6-572488ca9ca1@alliedtelesis.co.nz \
    --to=chris.packham@alliedtelesis.co.nz \
    --cc=andy.shevchenko@gmail.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.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
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).