Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp974569pxu; Mon, 23 Nov 2020 08:36:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJxRDYllDvoHn6x6CdYI2q6z8utvQYQoI0bSzPXludKRZemOu69TLgQHiWP3vmI+uLSmtQe+ X-Received: by 2002:a17:906:46d2:: with SMTP id k18mr393321ejs.33.1606149379433; Mon, 23 Nov 2020 08:36:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606149379; cv=none; d=google.com; s=arc-20160816; b=mNH/2GUYDAj6n2MKTZX/ZiYvSn3TLRvJ1siY8Pf28gN7Z3ZG83zDB3KGu9qCHafMoL pspKmSuE4TriS525UB8xl6Rnv8poQxIbAoTaUMuOiFlx2aePTm8dPrLaNBrBh8sBPJH4 JFDYTCA/KfGovRbs1ABrWIXW1WIlf8J1mP03Zr0QyeLCYl+fhtG5Ing3F6hfyDDQxCux GrjjbrBYDWaXuWRbQqmF08d0s+u8mF/IwLbLmJeJ/eSIFnighqVvkcOePtuGH1UvaW5p gWqo4QJ4sM5y9+woLfTPsAwvOUG0C9ii+I0oPZ3bIV2i+2Epp4P47SWRZzhIQ846QMQ1 5c3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:reply-to:cc:from:to :dkim-signature:date; bh=1OgKSLrOLrx4rcpdrxHRjSAEiZ/HKQ6P5WUtosWkqYE=; b=qUGx9XLb8jnYZt8EWetkded0ny75aGbogKwXmz12ti0MnGvGPl3R2HDDbHYqa8sPOF 4R64emh74yu16ngLb8boxsDmmaO7FWMuzpZvE/GEVg1OIq1mc0ZNIdbvtyBlY2MCjFpv sqm6lYDkMN9bRYQ9a4QLJUma/UW8BNHt07+IKH7utCsDrpK4Zi6PbJqVCwfPqXvwV/OS tFR2iC1fETpG4FslqGgXb2WpH8qfQnTh7U2OnkkdFMREtj3RUwshVCSCkT5bvg/oV0ZH x/uF0Awaog7hdoe050t/8jcY0xN2u53Pbbh/mNKo283UBe2zSrneL8YErEwZTBMkJPjl 6LJA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail header.b=hBHo2n7I; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u19si2999774ejo.278.2020.11.23.08.35.55; Mon, 23 Nov 2020 08:36:19 -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=@protonmail.com header.s=protonmail header.b=hBHo2n7I; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390052AbgKWQdV (ORCPT + 99 others); Mon, 23 Nov 2020 11:33:21 -0500 Received: from mail-40140.protonmail.ch ([185.70.40.140]:23456 "EHLO mail-40140.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390029AbgKWQcx (ORCPT ); Mon, 23 Nov 2020 11:32:53 -0500 Date: Mon, 23 Nov 2020 16:32:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1606149171; bh=1OgKSLrOLrx4rcpdrxHRjSAEiZ/HKQ6P5WUtosWkqYE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=hBHo2n7I9YQ9rdnnTyD6ot70VSuQ5JOy6OdbbL5v6CmBTOSsLQ/Kz4OC+GlEW6N59 U640d6Jx9w5e9cIsEkzP4T+Qf6ohVGn/kl2aKCtA/9KZCY8/5oUATwi2KSWnBK3QAh yNZ8jv+zsYlw7IyW89Vc0aOzyjuJBtMOLYzxJgcM= To: Coiby Xu From: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Cc: "linux-input@vger.kernel.org" , Helmut Stult , "stable@vger.kernel.org" , Jiri Kosina , Benjamin Tissoires , "linux-kernel@vger.kernel.org" Reply-To: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Subject: Re: [PATCH v3] HID: i2c-hid: add polling mode based on connected GPIO chip's pin status Message-ID: <1FeR4cJ-m2i5GGyb68drDocoWP-yJ47BeKKEi2IkYbkppLFRCQPTQT4D6xqVCQcmUIjIsoe9HXhwycxxt5XxtsESO6w4uVMzISa987s_T-U=@protonmail.com> In-Reply-To: <20201123143613.zzrm3wgm4m6ngvrz@Rk> References: <20201021134931.462560-1-coiby.xu@gmail.com> <20201122101525.j265hvj6lqgbtfi2@Rk> <20201123143613.zzrm3wgm4m6ngvrz@Rk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > [...] > >> >> +static int get_gpio_pin_state(struct irq_desc *irq_desc) > >> >> +{ > >> >> +=09struct gpio_chip *gc =3D irq_data_get_irq_chip_data(&irq_desc->= irq_data); > >> >> + > >> >> +=09return gc->get(gc, irq_desc->irq_data.hwirq); > >> >> +} > >> [...] > >> >> +=09ssize_t=09status =3D get_gpio_pin_state(irq_desc); > >> > > >> >`get_gpio_pin_state()` returns an `int`, so I am not sure why `ssize_= t` is used here. > >> > > >> > >> I used `ssize_t` because I found gpiolib-sysfs.c uses `ssize_t` > >> > >> // drivers/gpio/gpiolib-sysfs.c > >> static ssize_t value_show(struct device *dev, > >> =09=09struct device_attribute *attr, char *buf) > >> { > >> =09struct gpiod_data *data =3D dev_get_drvdata(dev); > >> =09struct gpio_desc *desc =3D data->desc; > >> =09ssize_t=09=09=09status; > >> > >> =09mutex_lock(&data->mutex); > >> > >> =09status =3D gpiod_get_value_cansleep(desc); > >> ... > >> =09return status; > >> } > >> > >> According to the book Advanced Programming in the UNIX Environment by > >> W. Richard Stevens, > >> With the 1990 POSIX.1 standard, the primitive system data type > >> ssize_t was introduced to provide the signed return value... > >> > >> So ssize_t is fairly common, for example, the read and write syscall > >> return a value of type ssize_t. But I haven't found out why ssize_t is > >> better int. > >> > > > > >Sorry if I wasn't clear, what prompted me to ask that question is the fo= llowing: > >`gc->get()` returns `int`, `get_gpio_pin_state()` returns `int`, yet you= still > >save the return value of `get_gpio_pin_state()` into a variable with typ= e > >`ssize_t` for no apparent reason. In the example you cited, `ssize_t` is= used > >because the show() callback of a sysfs attribute must return `ssize_t`, = but here, > >`interrupt_line_active()` returns `bool`, so I don't see any advantage o= ver a > >plain `int`. Anyways, I believe either one is fine, I just found it odd. > > > I don't understand why "the show() callback of a sysfs attribute > must return `ssize_t`" instead of int. Do you think the rationale > behind it is the same for this case? If yes, using "ssize_t" for > status could be justified. > [...] Because it was decided that way, `ssize_t` is a better choice for that purp= ose than plain `int`. You can see it in include/linux/device.h, that both the show() and store() methods must return `ssize_t`. What I'm arguing here, is that there is no reason to use `ssize_t` in this = case. Because `get_gpio_pin_state()` returns `int`. So when you do ``` ssize_t status =3D get_gpio_pin_state(...); ``` then the return value of `get_gpio_pin_state()` (which is an `int`), will b= e converted to an `ssize_t`, and saved into `status`. I'm arguing that that i= s unnecessary and a plain `int` would work perfectly well in this case. Anywa= ys, both work fine, I just found the unnecessary use of `ssize_t` here odd. Regards, Barnab=C3=A1s P=C5=91cze