netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: "René van Dorst" <opensource@vdorst.com>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: [PATCH] sfp: sfp_read: split-up request when hw rx buffer is too small.
Date: Fri, 25 Jan 2019 23:43:17 +0100	[thread overview]
Message-ID: <20190125224317.GI22211@lunn.ch> (raw)
In-Reply-To: <25fe50ef-d9f5-4a15-5f42-faf8b012416a@gmail.com>

> My point still stands, we have an abstraction layer through the i2c core
> which sits between clients and adapters.
> 
> If you have a simple read into a buffer transaction (like what we have
> here), then you can provide a safe accessor function that takes care of
> looking at the max_read_len quirk and splitting things into the
> appropriate number of transaction. Then we can also eliminate the "msg
> too long" annoying message since we are now using an appropriate function.
> 
> The fact that there are multiple drivers that need to be patched to
> split i2c transaction is an indication that this is not IMHO addressed
> at the right level, especially if what they do is as simple as an
> i2c_transfer() into a single buffer and require no quirky transaction.
> 
> Andrew, Heiner and Russell might have a different view on this.

Hi Florian

I suspect the issue is, only the driver knows if the device supports
splitting a read into multiple reads without having to do something in
between. Some device might require you do an address setup between
each read, for example.

However, the core could offer an i2c_transfer_segmentable(), which
does the segmentation as required here, and the driver can then elect
to use that, not i2c_transfer().

   Andrew

      reply	other threads:[~2019-01-25 22:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-23 21:20 [PATCH] sfp: sfp_read: split-up request when hw rx buffer is too small René van Dorst
2019-01-23 21:32 ` Andrew Lunn
2019-01-24 14:03   ` René van Dorst
2019-01-24 14:12     ` Andrew Lunn
2019-01-24 14:46       ` René van Dorst
2019-01-23 22:43 ` Florian Fainelli
2019-01-24 13:15   ` René van Dorst
2019-01-25 21:58     ` René van Dorst
2019-01-25 22:28       ` Florian Fainelli
2019-01-25 22:43         ` Andrew Lunn [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=20190125224317.GI22211@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=opensource@vdorst.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;
as well as URLs for NNTP newsgroup(s).