From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2DE5C282C0 for ; Fri, 25 Jan 2019 22:43:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 926B521855 for ; Fri, 25 Jan 2019 22:43:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="b29g1bja" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729446AbfAYWnY (ORCPT ); Fri, 25 Jan 2019 17:43:24 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:56167 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726179AbfAYWnY (ORCPT ); Fri, 25 Jan 2019 17:43:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=bt8d7SIGKmjMJZ+pGdICg/CQUvOg0e2XVEasDwt6q58=; b=b29g1bjaPX4jMdaazGmQ/SRW/b PI4B2V8wJShgqFOxYx4vzR0k4QH2Ok3tCQmC0ZQlz2YlplGGUT7CzoAQQka3IUC4/17Jkpjef12KW ymtBk893qB1AZWrQVuAn51GvA0NvbONwY2CaqjPOF82V1ii+JctxQTYo4091BQsnt4MI=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1gnABx-00008i-QG; Fri, 25 Jan 2019 23:43:17 +0100 Date: Fri, 25 Jan 2019 23:43:17 +0100 From: Andrew Lunn To: Florian Fainelli Cc: =?iso-8859-1?Q?Ren=E9?= van Dorst , Heiner Kallweit , "David S. Miller" , netdev@vger.kernel.org Subject: Re: [PATCH] sfp: sfp_read: split-up request when hw rx buffer is too small. Message-ID: <20190125224317.GI22211@lunn.ch> References: <20190123212046.13020-1-opensource@vdorst.com> <20190124131510.Horde.4Vz5bPgjqn22MgFWZL3Txy_@www.vdorst.com> <20190125215843.Horde.8SasDoteCejPU5IfJ0ibweV@www.vdorst.com> <25fe50ef-d9f5-4a15-5f42-faf8b012416a@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25fe50ef-d9f5-4a15-5f42-faf8b012416a@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > 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