From patchwork Fri Feb 12 17:03:50 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wolfram Sang X-Patchwork-Id: 1439942 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org (client-ip=23.128.96.18; helo=vger.kernel.org; envelope-from=linux-i2c-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; secure) header.d=sang-engineering.com header.i=@sang-engineering.com header.a=rsa-sha256 header.s=k1 header.b=TeWZXyF2; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by ozlabs.org (Postfix) with ESMTP id 4Dcfxy72dxz9sRf for ; Sat, 13 Feb 2021 04:05:10 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230376AbhBLREo (ORCPT ); Fri, 12 Feb 2021 12:04:44 -0500 Received: from www.zeus03.de ([194.117.254.33]:38292 "EHLO mail.zeus03.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229465AbhBLREm (ORCPT ); Fri, 12 Feb 2021 12:04:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=sang-engineering.com; h= from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; s=k1; bh=iJ/Viy3d4W4Tp4nXKMFzNdDVY8g HOpacrfQ9ONvrcy4=; b=TeWZXyF2RTMImSl8Hkull0aoqSYuHd7LcHUjqKm3kDZ hbUkC03jRuwyVC5ZW352iFxyIgvlDOIkbhgti9+DgHON8yoHwX4tgx2JWmiIJo/f KQd+9C/6M9rV9gC37tBoB+jnvlEY/EQBoZQObf6Gg4Sk6Z7CNGxflaVjzLllocc4 = Received: (qmail 1320473 invoked from network); 12 Feb 2021 18:03:59 +0100 Received: by mail.zeus03.de with ESMTPSA (TLS_AES_256_GCM_SHA384 encrypted, authenticated); 12 Feb 2021 18:03:59 +0100 X-UD-Smtp-Session: l3s3148p1@UDoVnya7GOwgAwDPXwX6ALT+xmQk9ITR From: Wolfram Sang To: linux-i2c@vger.kernel.org Cc: Wolfram Sang Subject: [PATCH] i2c: powermac: remove uncertainty about SMBUS_BLOCK transfers Date: Fri, 12 Feb 2021 18:03:50 +0100 Message-Id: <20210212170350.2491-1-wsa+renesas@sang-engineering.com> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org The driver does the correct thing, so no need to question it. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-powermac.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-powermac.c b/drivers/i2c/busses/i2c-powermac.c index 3e38e114948b..5241e6f414e9 100644 --- a/drivers/i2c/busses/i2c-powermac.c +++ b/drivers/i2c/busses/i2c-powermac.c @@ -76,11 +76,6 @@ static s32 i2c_powermac_smbus_xfer( struct i2c_adapter* adap, * but I think the current API makes no sense and I don't want * any driver that I haven't verified for correctness to go * anywhere near a pmac i2c bus anyway ... - * - * I'm also not completely sure what kind of phases to do between - * the actual command and the data (what I am _supposed_ to do that - * is). For now, I assume writes are a single stream and reads have - * a repeat start/addr phase (but not stop in between) */ case I2C_SMBUS_BLOCK_DATA: buf = data->block;