Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp212956pxu; Sun, 22 Nov 2020 05:38:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJxa5BGLiHQ7jJ3wyxhxv8SGkCAgr8B1/AqshDO0DaYoBDqHc8dogyFMsql5CkAJ265gyLX/ X-Received: by 2002:a17:906:d8b0:: with SMTP id qc16mr39922429ejb.268.1606052282353; Sun, 22 Nov 2020 05:38:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606052282; cv=none; d=google.com; s=arc-20160816; b=xOUG7RGs2UJscOrXlBp94P+KzaU5SixEhH3FvFb6+NLVPk4foPwUdEm9gkeSwoj6Rc ts9lK52sO4e6GpLpQXf2RpQijAlpKFI2RrIzZ8WrUi76ctFAazL8ViX84aShH3GLQFVM ybfQ/IueeQnXrzH3kVZa5ZkT2lvK+FcBLRXOtmuJARzNJtiMOrW6fi9k6/FxWbBYk1dH N9RfCDJ3K8uUqfc/HIhfAnRnwhecLrY1aCzFqg20uxDRIZ57f8OJgHvEkHa/asm1L3eE JiewpoXlF9sRuNBHaf0zve+DrBchZrwUCMWzVLZtAM04UJhKwavEKjLUJRfsjSbjU67X P6EQ== 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=NGfLf+2/UDS8HyaW78yoZusoy/lNepZl6zp7GO3POq4=; b=Iw+gYzu50FFL5jWFC2MTNSMvfEHyO83G4LpaSejNR7v8XRugJ5BqWlQklcSpls8cL6 8bEHYEzsU6GstU7Mhjnr9l4sCMBWngKirQXUxHLKQ6uXvXrnPc2lFUmPULx5HtRPPa/i p738yiCbhjnQLjkTI2mmBbcvfTXRcdsFVOfbO+lITLCySp8FHynPCaYRCvN3TeDV6gQ2 gjrUQ9ps2iiaQg/j9C3iWiABu5YzOFunqDuZVo0iC8bGDGUH73T0ZMQFgwvV7pyqcOn0 8+/gZX4mQ+hJxjmYD8EFB0U625B1Xeczn7yUCJOdaR9Jn107X05Pbe1s9SxcTaGxKLM2 YgjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail header.b=exdWE6k6; 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 u17si3580408edv.131.2020.11.22.05.37.39; Sun, 22 Nov 2020 05:38:02 -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=exdWE6k6; 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 S1727835AbgKVNdM (ORCPT + 99 others); Sun, 22 Nov 2020 08:33:12 -0500 Received: from mail-40140.protonmail.ch ([185.70.40.140]:56799 "EHLO mail-40140.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727702AbgKVNdM (ORCPT ); Sun, 22 Nov 2020 08:33:12 -0500 Date: Sun, 22 Nov 2020 13:33:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1606051989; bh=NGfLf+2/UDS8HyaW78yoZusoy/lNepZl6zp7GO3POq4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=exdWE6k68YH+uJsIPhr9xzHVoeeJFakjTYw+VEh0P1Zp5BXi1sXFKc+UeRl5C5/gO w+dR8PmwIfa6FL9auxAEL44O+BTn4W9uWn2p05dkOIG592LOoXcHLkymrDI3lTJ6D1 eHljNVUH7UVGRqOFjQNC1kgJaGPd4lAr8SFbGfa8= 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: In-Reply-To: <20201122101525.j265hvj6lqgbtfi2@Rk> References: <20201021134931.462560-1-coiby.xu@gmail.com> <20201122101525.j265hvj6lqgbtfi2@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 Hi 2020. november 22., vas=C3=A1rnap 11:15 keltez=C3=A9ssel, Coiby Xu =C3= =ADrta: > [...] > >> +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 follo= wing: `gc->get()` returns `int`, `get_gpio_pin_state()` returns `int`, yet you st= ill save the return value of `get_gpio_pin_state()` into a variable with type `ssize_t` for no apparent reason. In the example you cited, `ssize_t` is us= ed 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 over= a plain `int`. Anyways, I believe either one is fine, I just found it odd. > >> + > >> +=09if (status < 0) { > >> +=09=09dev_warn(&client->dev, > >> +=09=09=09 "Failed to get GPIO Interrupt line status for %s", > >> +=09=09=09 client->name); > > > >I think it's possible that the kernel message buffer is flooded with the= se > >messages, which is not optimal in my opinion. > > > Thank you! Replaced with dev_dbg in v4. > [...] Have you looked at `dev_{warn,dbg,...}_ratelimited()`? Regards, Barnab=C3=A1s P=C5=91cze