From: Wolfram Sang <wsa@kernel.org>
To: Marek Behun <marek.behun@nic.cz>
Cc: "Russell King - ARM Linux admin" <linux@armlinux.org.uk>,
"Andrew Lunn" <andrew@lunn.ch>,
netdev@vger.kernel.org, "Pali Rohár" <pali@kernel.org>,
linux-i2c@vger.kernel.org
Subject: Re: question about i2c_transfer() function (regarding mdio-i2c on RollBall SFPs)
Date: Fri, 8 Jan 2021 09:40:51 +0100 [thread overview]
Message-ID: <20210108084051.GA1223@kunai> (raw)
In-Reply-To: <20210107224211.4f01c055@nic.cz>
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]
> I thought as much, but maybe there is some driver which can offload
> whole i2c_transfer to HW, and has to pass the addresses of the buffers
> to the HW, and the HW can have problems if the buffers overlap
> somewhere...
Well, sure, you can never know what crazy HW is out there :) But that
shouldn't prevent us from doing legit I2C transfers. The likeliness of
such HW is low enough; They must process the whole transfer in one go
(rare) AND have the limitiation with the buffer pointers (at least I
don't know one) AND have no possibility of a fallback to a simpler mode
where they can handle the transfer per message. If such a controller
exists, it would need a new quirk flag, I'd say, and reject the
transfer. But that shouldn't stop you from fixing your issue.
Thanks for thinking thoroughly about drawbacks! Much appreciated.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2021-01-08 8:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-07 18:25 question about i2c_transfer() function (regarding mdio-i2c on RollBall SFPs) Marek Behun
2021-01-07 21:02 ` Wolfram Sang
2021-01-07 21:42 ` Marek Behun
2021-01-08 8:40 ` 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=20210108084051.GA1223@kunai \
--to=wsa@kernel.org \
--cc=andrew@lunn.ch \
--cc=linux-i2c@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=marek.behun@nic.cz \
--cc=netdev@vger.kernel.org \
--cc=pali@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.