Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp373408pxb; Tue, 1 Feb 2022 01:34:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJyGn7WYIPsyeKC91gzQI8+iylxwDQsKKH/xIQ/HJC2fEkgsqXZ5sDyMT1ErGgljA0BdoHn6 X-Received: by 2002:a17:907:7ea4:: with SMTP id qb36mr19413421ejc.551.1643708054810; Tue, 01 Feb 2022 01:34:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643708054; cv=none; d=google.com; s=arc-20160816; b=EN5mBChbUeXta8KxTpuIEqWy4vnLsYFrbPU+Ldi2qPmXCmgdMdpAHzZ9HxTYe5MWtp 1q497Fg9ID10Rk5hIrIgwJCnxPRFkevK98VgDQOZQpi1Uu5LQWnDiKFp4CHZ2wHZWk++ He63vysbuV6SpffryHbPRW+Me6vMYv3My9SIdDXkUwityw07JxPwvPdh4BCGq5C6Fp8P rc0wHZYY4j2jt8OuW/yqTXU1aPeVkpwtL/DuZFsHMsHgjEO6qlw0uGSlaaL5TXoxhuL8 SHwoTpR4FB4mb3jomCqLa+6N9ouO4hfAjP/mFgwqZUTeN29x3O1TLk8pXr6x8llmL+wI zSkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :to:subject:dkim-signature:dkim-signature; bh=U9JcbIOM16hUc2t5ADAkVHd0VUGSahY0TtGmGl7TQ3E=; b=ercU6EyonfPwF2HC+fAYtn5799LlN8CDC2WMIIr4+u5zOuzlEB3UtGQGKx/j8vnSYy bkkK9g8xQdYKNMXz+xzGwSv/GryP+8r9Fr3LCu/0BT5Q6fP6Vv+2ahVFRAufm3ABs01M aDdX4xneRwmMkvHWXJSvOq+cH1UYmBukKvTNg3QqiDQXx8lH6cSiQ9pCQRYvKP8h2pf1 1K3l/ienPPbBMjhyJL8VVlbXAoewnD8autfQNTaRmVpeMvQJ2S6R5pai4bjCy/ksiZ3M 8q5cLjnaGwdJgsYey8k9nb+1l4yerZUVnmWHUarc2Yvudsk/vZEUHNVZA2+mKXCbwRzp tZ8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sholland.org header.s=fm1 header.b=T7wblD8J; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=TsFanyXT; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a20si9065751eda.71.2022.02.01.01.33.49; Tue, 01 Feb 2022 01:34:14 -0800 (PST) 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=@sholland.org header.s=fm1 header.b=T7wblD8J; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=TsFanyXT; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240758AbiA3Cnf (ORCPT + 99 others); Sat, 29 Jan 2022 21:43:35 -0500 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:60129 "EHLO wout3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230484AbiA3Cnd (ORCPT ); Sat, 29 Jan 2022 21:43:33 -0500 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 95D023200BF9; Sat, 29 Jan 2022 21:43:32 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sat, 29 Jan 2022 21:43:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sholland.org; h= cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; bh=U9JcbIOM16hUc2 t5ADAkVHd0VUGSahY0TtGmGl7TQ3E=; b=T7wblD8JDI868UsiNj+iPoctBKOe0R FyXLG3DYktdBaGN9UP0C03eruBKRqlohGj0HtYiRCtFILQ7l1YjmhzybDQyY4da/ cF4OJhkcdC2DvgMF3R1dN1a2NPzvallSYzFMixuNe5XG490YvKw4ERpFRDu7mBrb bbNMienovIRJ3eU9ghK2HKh+UacO8944+69PuKtqdJDz88gr5uVd0ejRB1Cy4F+z FXDVo2Ru/JvMwKcJPhTaoChjnLcSxc3QU0k8s3BFhhOkIuhdYi6mnpIA8htajAlM R4qHalFSOnDMDu0KCyVddBtPLoGKx0X8mNBZGF8icbmtYKPTHaLxRArg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=U9JcbIOM16hUc2t5ADAkVHd0VUGSahY0TtGmGl7TQ3E=; b=TsFanyXT WUhomasnYw3bez+dEKzshI04ul8k2yiCcfpAvIvftPKKPBtbjeg7WkMWv4jgFBOe AIB2N7oj0ira9uDWijj7Eh6C6OQgvz1+KZTFvWBayccwjtcw61lmcZL6jVsZokOw PjvjFVtljNavCxYtNaaNYt0xLUt1xdQKRnwXEfzLbCqSl6QcPSOS/6udO6r5c+Pp EjFXeUFX4RmtsIDsvnczKPc26iRJnlE1sZOa2a5iUVUV3QqYERgkdTKiNRCjBLu9 quEPqQqdqgxNcoOpJkYy80s0+Jnp65ih7tCfnkxJe8uMvhbH1U89s43Ew65VCs2x 6krxk7etJdCjJA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrfeekgdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefurghmuhgv lhcujfholhhlrghnugcuoehsrghmuhgvlhesshhhohhllhgrnhgurdhorhhgqeenucggtf frrghtthgvrhhnpefgleekudevjedtjefhieelvdfhgeegieeikeelhfeffeffffffgedu teetleeijeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehsrghmuhgvlhesshhhohhllhgrnhgurdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 29 Jan 2022 21:43:31 -0500 (EST) Subject: Re: [PATCH 4/5] Input: pinephone-keyboard - Support the proxied I2C bus To: =?UTF-8?Q?Ond=c5=99ej_Jirman?= , Dmitry Torokhov , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Rob Herring , devicetree@vger.kernel.org, linux-i2c@vger.kernel.org, Wolfram Sang References: <20220129230043.12422-1-samuel@sholland.org> <20220129230043.12422-5-samuel@sholland.org> <20220130020523.f7mx36yj6nlqthoe@core.my.home> From: Samuel Holland Message-ID: <4d642ba4-bd34-814d-8ae1-c90c87fa4bc4@sholland.org> Date: Sat, 29 Jan 2022 20:43:30 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20220130020523.f7mx36yj6nlqthoe@core.my.home> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/29/22 8:05 PM, Ondřej Jirman wrote: > Hello Samuel, > > On Sat, Jan 29, 2022 at 05:00:41PM -0600, Samuel Holland wrote: >> The PinePhone keyboard case contains a battery managed by an integrated >> power bank IC. The power bank IC communicates over I2C, and the keyboard >> MCU firmware provides an interface to read and write its registers. >> Let's use this interface to implement a SMBus adapter, so we can reuse >> the driver for the power bank IC. >> >> Signed-off-by: Samuel Holland >> --- >> >> drivers/input/keyboard/pinephone-keyboard.c | 73 +++++++++++++++++++++ >> 1 file changed, 73 insertions(+) >> >> diff --git a/drivers/input/keyboard/pinephone-keyboard.c b/drivers/input/keyboard/pinephone-keyboard.c >> index 8065bc3e101a..7d2e16e588a0 100644 >> --- a/drivers/input/keyboard/pinephone-keyboard.c >> +++ b/drivers/input/keyboard/pinephone-keyboard.c >> @@ -3,6 +3,7 @@ >> // Copyright (C) 2021-2022 Samuel Holland >> >> #include >> +#include >> #include >> #include >> #include >> @@ -23,6 +24,11 @@ >> #define PPKB_SCAN_DATA 0x08 >> #define PPKB_SYS_CONFIG 0x20 >> #define PPKB_SYS_CONFIG_DISABLE_SCAN BIT(0) >> +#define PPKB_SYS_SMBUS_COMMAND 0x21 >> +#define PPKB_SYS_SMBUS_DATA 0x22 >> +#define PPKB_SYS_COMMAND 0x23 >> +#define PPKB_SYS_COMMAND_SMBUS_READ 0x91 >> +#define PPKB_SYS_COMMAND_SMBUS_WRITE 0xa1 >> >> #define PPKB_DEFAULT_KEYMAP_ROWS 6 >> #define PPKB_DEFAULT_KEYMAP_COLS 12 >> @@ -132,6 +138,7 @@ static const struct matrix_keymap_data ppkb_default_keymap_data = { >> }; >> >> struct pinephone_keyboard { >> + struct i2c_adapter adapter; >> struct input_dev *input; >> unsigned short *fn_keymap; >> u8 crc_table[CRC8_TABLE_SIZE]; >> @@ -143,6 +150,57 @@ struct pinephone_keyboard { >> u8 buf[]; >> }; >> >> +static int ppkb_adap_smbus_xfer(struct i2c_adapter *adap, u16 addr, >> + unsigned short flags, char read_write, >> + u8 command, int size, >> + union i2c_smbus_data *data) >> +{ >> + struct i2c_client *client = adap->algo_data; >> + u8 buf[3]; >> + int ret; >> + >> + buf[0] = command; >> + buf[1] = data->byte; >> + buf[2] = read_write == I2C_SMBUS_READ ? PPKB_SYS_COMMAND_SMBUS_READ >> + : PPKB_SYS_COMMAND_SMBUS_WRITE; >> + >> + ret = i2c_smbus_write_i2c_block_data(client, PPKB_SYS_SMBUS_COMMAND, >> + sizeof(buf), buf); >> + if (ret) >> + return ret; > > [1] > >> + /* Read back the command status until it passes or fails. */ >> + do { >> + usleep_range(300, 500); >> + ret = i2c_smbus_read_byte_data(client, PPKB_SYS_COMMAND); >> + } while (ret == buf[2]); >> + if (ret < 0) >> + return ret; >> + /* Commands return 0x00 on success and 0xff on failure. */ >> + if (ret) >> + return -EIO; >> + >> + if (read_write == I2C_SMBUS_READ) { >> + ret = i2c_smbus_read_byte_data(client, PPKB_SYS_SMBUS_DATA); >> + if (ret < 0) >> + return ret; > > Please use a single read transfer to get both command result and data. > There will be less risk that some userspace app will issue another command > in between command status being read as 0 and data byte being read. > > Otherwise if you use this in some read/modify/write operation, you > may write unexpected value to PMIC. I2C register layout is designed > to make this as optimal as possible in a single I2C transaction, so > you only need 3 bytes to start command and 2 bytes to read the result > and data, both in a single xfer. There's very high likelihood the command > will complete in those 300 - 500 us anyway, because the timing is > predictable. If this delay is set right, it's almost guaranteed, > only two xfers will be necessary to run the command and get the result+ > status. I did this originally, but it causes a different race condition: since the data is read first, the command can complete between when the data is read and when the result is read. If this happens, the command will be seen as complete, but the data will be garbage. This caused occasional read errors for the charger's power supply properties, because I2C reads sometimes returned nonsensical values for those bytes. > And if possible, it would be best if the bus was somehow made busy for > other users, until the whole comand/result sequence completes, to eliminate > the possibility of another command being issued by other bus users > around [1]. Yes, I can add a call to i2c_lock_bus() here. Regards, Samuel > Thank you and kind regards, > o. > >> + data->byte = ret; >> + } >> + >> + return 0; >> +} >> + >> +static u32 ppkg_adap_functionality(struct i2c_adapter *adap) >> +{ >> + return I2C_FUNC_SMBUS_BYTE_DATA; >> +} >> + >> +static const struct i2c_algorithm ppkb_adap_algo = { >> + .smbus_xfer = ppkb_adap_smbus_xfer, >> + .functionality = ppkg_adap_functionality, >> +}; >> + >> static int ppkb_set_scan(struct i2c_client *client, bool enable) >> { >> struct device *dev = &client->dev; >> @@ -265,6 +323,7 @@ static int ppkb_probe(struct i2c_client *client) >> unsigned int map_rows, map_cols; >> struct pinephone_keyboard *ppkb; >> u8 info[PPKB_MATRIX_SIZE + 1]; >> + struct device_node *i2c_bus; >> int ret; >> >> ret = i2c_smbus_read_i2c_block_data(client, 0, sizeof(info), info); >> @@ -312,6 +371,20 @@ static int ppkb_probe(struct i2c_client *client) >> >> i2c_set_clientdata(client, ppkb); >> >> + i2c_bus = of_get_child_by_name(dev->of_node, "i2c-bus"); >> + if (i2c_bus) { >> + ppkb->adapter.owner = THIS_MODULE; >> + ppkb->adapter.algo = &ppkb_adap_algo; >> + ppkb->adapter.algo_data = client; >> + ppkb->adapter.dev.parent = dev; >> + ppkb->adapter.dev.of_node = i2c_bus; >> + strscpy(ppkb->adapter.name, DRV_NAME, sizeof(ppkb->adapter.name)); >> + >> + ret = devm_i2c_add_adapter(dev, &ppkb->adapter); >> + if (ret) >> + return dev_err_probe(dev, ret, "Failed to add I2C adapter\n"); >> + } >> + >> crc8_populate_msb(ppkb->crc_table, PPKB_CRC8_POLYNOMIAL); >> ppkb->row_shift = get_count_order(map_cols); >> ppkb->rows = map_rows; >> -- >> 2.33.1 >>