Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1778528ybt; Mon, 15 Jun 2020 09:10:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwe/MZaXgIEyqLFXTl8W5WaD5tVsTPGO2T5OKEctLmGYSoeSA2/2KvSfA2zQVWApl1X8CeZ X-Received: by 2002:a17:906:1f0d:: with SMTP id w13mr14549008ejj.0.1592237414961; Mon, 15 Jun 2020 09:10:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592237414; cv=none; d=google.com; s=arc-20160816; b=a6n4cSS1QYl6/g55PbwoOatjXlJkDOAcX6wMly7KLtDNYmkW9gfeJ7hSnODScZ80gF 5f+zuLyBEakUW3OCTADE9FTbcxYgFLFmUGO8puCxOm/6e4Oxk+eqxQCanbQkbdxHLoqq +f9eG4Lf+5Eyp12CS1ssTQHtRZEPipcj407BLJpI6U1JWlnT35UNrqDupJLKBSakjNjc 4RkUMO15pljkOmOt1h3iZmSnRbM4Z+n199EMB1R/cysfwWsze5P4/LvaifCImmF/6bQG hX4qXxIEoAb28S+m90VVo60K5vVRtq3xgCBEQbQK/Orlc5J5jL5xbrLkCPv/+8YWeGwF dd6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=vbAqJspBEy3qPmYLBAGhLz99Oyo1IaGAYVCtozwHP14=; b=TQkZO5ZHt92qZ53S38scGZfjsfw7/80/Mcf1pb84jbGn9J0gFjKkyHAPGUpa3Ol3W1 yLHJ4Bv+S7fhaC2FMDEx9d+GUvdHXvZjYwc/wdU7lopxhJSFnQ7ZGvw1nrBr8y8ULFY7 tE23KCWDRpclDKIh1oNRLcAqhZ6esdQyxSIYA6L404U/iAhwxrivZQkn1rr0/jVnnW9Z YXyj4DoKfB6x8cqYVxN9J855DhYlsZHo0slDIFIDBSH4ctVyIJIe5EffgoxoVpMuzVSQ izSf7iFd0f3l+yJVXe/dd4I2AhftMmN2XB9SCMBW170QRbzMn3gZ6SsLESBXy8PyOPBo AmUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=K3tMyfHD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g6si9319497edf.480.2020.06.15.09.09.52; Mon, 15 Jun 2020 09:10:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=K3tMyfHD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730565AbgFOQH4 (ORCPT + 99 others); Mon, 15 Jun 2020 12:07:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729772AbgFOQHz (ORCPT ); Mon, 15 Jun 2020 12:07:55 -0400 Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 07ADAC061A0E; Mon, 15 Jun 2020 09:07:55 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id s10so7803438pgm.0; Mon, 15 Jun 2020 09:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vbAqJspBEy3qPmYLBAGhLz99Oyo1IaGAYVCtozwHP14=; b=K3tMyfHDMU23lAAyeTy3R5+F+8tyV4F19bGC4jPgVkfFDReb++iNlqxZ4oV5dGt0II FxvF5FxulOHAwY5RTyXjpLUS9imSH/JqLleM9vPsu4aJgd8D+oDXgMTSyOW5IdRpPfa9 d/PhvNOuS5DKM3chalq7BOKTVq/cwnseug70HAXC3DFOI3I+47mDmDfu0AOHHuvcjRFf kg2EASmKr9fivAHe4QHbQODrHpiStZ088UaaFW7zSYJC98U5qyLGyPXAGRgiFrcD8Dxl S2gqi7R0oliDmRVgRBeBYl2aQ73WaAdwaTbw1xyU9xAmj5UA/1cZWgdMPq3IFXuxmLw1 PJxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vbAqJspBEy3qPmYLBAGhLz99Oyo1IaGAYVCtozwHP14=; b=fjYOf9wsnqNIBtkUxgJRpwyd4JkpVPqGytPjoj4UKkYGSpAr2B7/s9bMSjgkiBeZHJ wQZ4cW4PJWgVYI+/2UMk7J0r4QIfIGzHtX5ySfX3+ryHfIm8pirCicz7qalpG/EKnuNQ vu1ifMZYxrY80W94nxeKI7jjpZluP4EUbrm/xnkPq/21R/J8vj4vSzzihLHomQNpN1gW QX3GZyweWhIM88/iZIDJ2ttDd1bu2rkEnU+6Ia4afOkhJoMUZQ9UBKxb2jULp+nq3T1M oBntoe73J+ZQ5avA134CMZ7XgGlVw9FrFMozqHymNadTiyyu7Ts7eG7X9R28/8/NG/Fo 7QGA== X-Gm-Message-State: AOAM532PUsM2zx8eDHFikkm205bT0r+vaxlSC5UJmFhi1PxxD2t0S8c0 6ueOzHqMTv5l3CpBmZn5wCXJPtxNUEYI+477MCc= X-Received: by 2002:a63:305:: with SMTP id 5mr21153696pgd.74.1592237274446; Mon, 15 Jun 2020 09:07:54 -0700 (PDT) MIME-Version: 1.0 References: <20200614210255.4641-1-sultan@kerneltoast.com> <20200614210255.4641-2-sultan@kerneltoast.com> <20200615094019.GP2428291@smile.fi.intel.com> <20200615160320.GA1949@sultan-book.localdomain> In-Reply-To: <20200615160320.GA1949@sultan-book.localdomain> From: Andy Shevchenko Date: Mon, 15 Jun 2020 19:07:42 +0300 Message-ID: Subject: Re: [PATCH 1/2] i2c: designware: Only check the first byte for SMBus block read length To: Sultan Alsawaf Cc: Andy Shevchenko , Aaron Ma , Benjamin Tissoires , Hans de Goede , HungNien Chen , Jarkko Nikula , Jiri Kosina , Kai-Heng Feng , linux-i2c , linux-input , Linux Kernel Mailing List , Mika Westerberg , Pavel Balan , Tin Huynh , Wolfram Sang , You-Sheng Yang Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 15, 2020 at 7:06 PM Sultan Alsawaf wrote: > On Mon, Jun 15, 2020 at 12:40:19PM +0300, Andy Shevchenko wrote: > > On Sun, Jun 14, 2020 at 02:02:54PM -0700, Sultan Alsawaf wrote: > > > From: Sultan Alsawaf > > > > > > SMBus block reads can be broken because the read function will just skip > > > over bytes it doesn't like until reaching a byte that conforms to the > > > length restrictions for block reads. This is problematic when it isn't > > > known if the incoming payload is indeed a conforming block read. > > > > > > According to the SMBus specification, block reads will only send the > > > payload length in the first byte, so we can fix this by only considering > > > the first byte in a sequence for block read length purposes. > > > > I'm wondering if this overlaps with [1]. AFAIU that one is also makes sure that > > the length is not a garbage. > > > > [1]: https://lore.kernel.org/linux-i2c/20200613104109.2989-1-mans@mansr.com/T/#u > > No overlap. Thanks for clarifying. > That looks like a similar bug for a different driver. In my case, > the adapter provides native SMBus support, so emulation is never used. This is > clear to see by looking at i2c_transfer_buffer_flags(), which only uses the > master_xfer functions provided by the adapter; it doesn't call the emulation > path at all. But do we get an advantage if this can be done in the i2c core instead (once for all)? -- With Best Regards, Andy Shevchenko