All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Edwards <cfsworks@gmail.com>
To: Gregory CLEMENT <gregory.clement@bootlin.com>,
	Andi Shyti <andi.shyti@kernel.org>
Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RESEND v2 RFC 0/5] Enhancements for mv64xxx I2C driver
Date: Tue, 19 Mar 2024 18:44:56 -0600	[thread overview]
Message-ID: <65fa7599.5d0a0220.fe5f7.1f9f@mx.google.com> (raw)

Salutations, Linux I2C team!

Apologies again for another resend; I'm just as surprised as you all that
modern email clients are so hostile to sending the exact byte-for-byte .mbox
given to them. Really wishing I could use git-send-email and be done with it.
But, third time's the charm!

I am working with an Allwinner T113-s3 based board; the internal I2C bus of
which has a Realtek RTL8370MB-CG Ethernet switch coexisting with other I2C
devices. The RTL8370MB-CG deviates from "conventional" I2C read operations
in that it expects the hardware register after the addr+read byte before it
turns around the bus to send the value. For this reason, the `realtek-smi`
driver currently implements the protocol via bit-banging. However, I am in the
process of developing a separate patch series to promote this driver to a
"full" I2C driver, leveraging I2C_M_NOSTART to support this odd read operation.

In anticipation of that, I am preparing this series comprising five patches to
improve the functionality and reliability of the I2C adapter enough to support
this kind of device. I have heavily tested these changes on the Allwinner-style
mv64xxx core, but not the Marvell-style, and have not been able to test 10-bit
addressing. I would greatly appreciate if anyone here could test this series,
especially on non-Allwinner boards and/or boards with 10-bit devices.

I'm a bit skeptical of using I2C_M_NOSTART for this purpose. The driver does
not (and cannot) support "just any" use of I2C_M_NOSTART, so it may be
inappropriate to claim the I2C_FUNC_NOSTART capability. On the other hand, I
searched high and low and couldn't find any use of I2C_M_NOSTART that
*wouldn't* be supported by this change, so this could very well be exactly what
clients understand I2C_FUNC_NOSTART to mean. Given that the alternative would
be inventing a new flag ("I2C_M_READEXTRA"?) and figuring out how to supply
input bytes and output bytes in the same i2c_msg, I opted for the NOSTART
route instead.

I look forward to any feedback, bug reports, test results, questions, concerns,
commentary, or discussion that you can offer!

Best regards,
Sam

Sam Edwards (5):
  i2c: mv64xxx: Clear bus errors before transfer
  i2c: mv64xxx: Clean up the private data struct
  i2c: mv64xxx: Refactor FSM
  i2c: mv64xxx: Allow continuing after read
  i2c: mv64xxx: Implement I2C_FUNC_NOSTART

 drivers/i2c/busses/i2c-mv64xxx.c | 430 ++++++++++++++++++++++---------
 1 file changed, 302 insertions(+), 128 deletions(-)

-- 
2.43.2


             reply	other threads:[~2024-03-20  5:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-20  0:44 Sam Edwards [this message]
2024-03-30  0:06 ` [RESEND v2 RFC 0/5] Enhancements for mv64xxx I2C driver Andi Shyti
2024-04-02 12:17   ` Gregory CLEMENT

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=65fa7599.5d0a0220.fe5f7.1f9f@mx.google.com \
    --to=cfsworks@gmail.com \
    --cc=andi.shyti@kernel.org \
    --cc=gregory.clement@bootlin.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.