Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp890313pxu; Mon, 23 Nov 2020 06:43:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJzZ2TbrqniFry02dBuC83yy6LV5R7R9syIfW9+I0P2Qq3dI2cUqKAsZBVQLwVyFWieLdFQ8 X-Received: by 2002:a17:906:ad8c:: with SMTP id la12mr43289443ejb.521.1606142639163; Mon, 23 Nov 2020 06:43:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606142639; cv=none; d=google.com; s=arc-20160816; b=q9CuV6a8te0mk/hYyO74bIaVpCqM4n98BK6zmEjFJVBUSyRs3LSZUXN8gIKuGVBCYV SeBnfovsyzxzbAA/ARttpH49nX1MzW5Stfo5GJT7pTR4Wfv1x3lcBV4ITz0PfKTLuotT n/kqofRXF9Nwyg3L/X8fFvQmdRuUk9KVC4SVF4esfDQllWYmOJTC0xkjyHKlXtQLFeIF sJqT7mZI+Zj2P9vo7zGYgfKlOH+csmonpomsZJWYtCpb5rdZL4AeLlTBATfVd59Ir49d J9LNUEm0zsATSIeVt90y2KiA3wqVEPaMtW+wopefnNFmRVPcneGmWVJPl92gbQgNF99r pfYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:date:from:dkim-signature; bh=fM4j6RxSfo5XXrx0DZNKP61g+fXLGOf6UqMSA1kliTM=; b=nJd3y38BoN7wyIOvNnn7YfUEtA8kBSDEb2YIV0KOTf9+USKhCo/y4qfI2r4j9NDbdy 3uKpPctaAUExtB2SgPfEsEIdvt/PJRNCLgqCSPg61bx6cI0Ck2AD+M4S9h/YmJA77FQH RlT6YlV4NjVD1RRkE34WL6uzVpJorSqdhFza4IsPgi/Ycgd1A1JQ25Bp0o5dMmzT5Fnv z/JK/VWNjMjafcsbmNPKEHNpxdl8lz3Sgn4YO5EhXR5XhmvGcHNUg2NPT3A214TwastG tnwy1TYJFPCX/gwAzneshkIlUcDKOcLzDFp71CcJ72X+/syFeyA4E2kjtjoGocJXYeqI 3DlA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=n4arlp4W; 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 m7si3673501edv.566.2020.11.23.06.43.36; Mon, 23 Nov 2020 06:43:59 -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=@gmail.com header.s=20161025 header.b=n4arlp4W; 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 S1728924AbgKWOjt (ORCPT + 99 others); Mon, 23 Nov 2020 09:39:49 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726745AbgKWOjs (ORCPT ); Mon, 23 Nov 2020 09:39:48 -0500 Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B376CC0613CF; Mon, 23 Nov 2020 06:39:48 -0800 (PST) Received: by mail-pf1-x441.google.com with SMTP id n137so5046568pfd.3; Mon, 23 Nov 2020 06:39:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=fM4j6RxSfo5XXrx0DZNKP61g+fXLGOf6UqMSA1kliTM=; b=n4arlp4WrfAdV9Al4lHHmjtOFo/jH6SuDDse9onYIq4yhjSioHU3iYpJwH138yPrzY LBZUQagNqnrgPF4JILY/I9bN9EEwTimM4alYTZYbk2J7o7tx2Xgskt9xYPnr1+FrnLKp SiJzWibdOTZyz6shXUuOmNzFNDbSef02QEkSNV8RSWiLgutHrLk7SROluh7zkmH4xAsd /qQ4syQ9U7CoiJml/LkXllebqwpPiavQl7hWJ+jgGXhxdbFXw035Vxdh51aj71Bnxu2k O3BvsEe3FSKebtpwF4efadGrMJwytMR6hvhcmH+TqvDJ89ntx2gZXmehfnE0H3ZviBLH b/hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=fM4j6RxSfo5XXrx0DZNKP61g+fXLGOf6UqMSA1kliTM=; b=RMoVH3Y7LOmBkDTED9TxiKLlkSP1k9WPIaSjohZsu0UnWFv8US4K/NbMudEqkV8qo+ pAO86Wltwo7mu7ClE/TkzQzhwQONEObzULFNIoRy3qd4Wf/Kr/JTmjvQNus0nEsMWYtS E+HYw6qS7wCs9zusnnG0BTbwTUK5AijOqZe+MF5F6KMTw7dUxi43LOF7hNkJknQ9rbUu XTzPuMl/8SezouDMPCiYhLrr/C12jYOox4cGyuw/u0cP18M2FSNEia/DyrLxJpDtfyX3 fEHf6YcsxZc4X77Ps1kE6JJmZFuYGBFAtW8Zxg+DgJ6ad57dnXOLrqyQ3WcboT8Jplr2 fwCA== X-Gm-Message-State: AOAM531jehvpL/xGrU8D93ziFz88cGt4bgbin0RXuP5Dktjip+UJpvZn ac8p0Q7i/E9JhfFy5zM2AVU= X-Received: by 2002:a17:90b:a43:: with SMTP id gw3mr22pjb.189.1606142387596; Mon, 23 Nov 2020 06:39:47 -0800 (PST) Received: from localhost ([2001:e42:102:1532:160:16:113:140]) by smtp.gmail.com with ESMTPSA id m13sm2087797pfa.115.2020.11.23.06.39.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Nov 2020 06:39:46 -0800 (PST) From: Coiby Xu X-Google-Original-From: Coiby Xu Date: Mon, 23 Nov 2020 22:36:13 +0800 To: =?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" Subject: Re: [PATCH v3] HID: i2c-hid: add polling mode based on connected GPIO chip's pin status Message-ID: <20201123143613.zzrm3wgm4m6ngvrz@Rk> References: <20201021134931.462560-1-coiby.xu@gmail.com> <20201122101525.j265hvj6lqgbtfi2@Rk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Nov 22, 2020 at 01:33:01PM +0000, Barnabás Pőcze wrote: >Hi > > >2020. november 22., vasárnap 11:15 keltezéssel, Coiby Xu írta: > >> [...] >> >> +static int get_gpio_pin_state(struct irq_desc *irq_desc) >> >> +{ >> >> + struct gpio_chip *gc = irq_data_get_irq_chip_data(&irq_desc->irq_data); >> >> + >> >> + return gc->get(gc, irq_desc->irq_data.hwirq); >> >> +} >> [...] >> >> + ssize_t status = 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, >> struct device_attribute *attr, char *buf) >> { >> struct gpiod_data *data = dev_get_drvdata(dev); >> struct gpio_desc *desc = data->desc; >> ssize_t status; >> >> mutex_lock(&data->mutex); >> >> status = gpiod_get_value_cansleep(desc); >> ... >> return 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 following: >`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 type >`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 over 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. > >> >> + >> >> + if (status < 0) { >> >> + dev_warn(&client->dev, >> >> + "Failed to get GPIO Interrupt line status for %s", >> >> + client->name); >> > >> >I think it's possible that the kernel message buffer is flooded with these >> >messages, which is not optimal in my opinion. >> > >> Thank you! Replaced with dev_dbg in v4. >> [...] > >Have you looked at `dev_{warn,dbg,...}_ratelimited()`? > Thank you for pointing me to these functions! > >Regards, >Barnabás Pőcze -- Best regards, Coiby