Received: by 10.223.185.116 with SMTP id b49csp3999920wrg; Mon, 26 Feb 2018 09:28:11 -0800 (PST) X-Google-Smtp-Source: AH8x224sNRO0YHqvZquvfhsQeEPGpeGJ4NYuKgDZON4KxZTlxGOaxoZwBliKnzfB4gPTJRzIvzPy X-Received: by 10.98.32.200 with SMTP id m69mr11258283pfj.82.1519666090983; Mon, 26 Feb 2018 09:28:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519666090; cv=none; d=google.com; s=arc-20160816; b=ou2XyyEa5mSpbjxV99il+6klkUTW1fFdQxUKt7vKBO2aab/rNYNHBzpLrDwax1trCm svo+JRbvlO2WDQsVS2v1kqCkCuJ32mf1HfUw+Eh3v1BkIsesHBno0W7SJ32cWaivVXNo vJloPJTIL1O6FCbgdQTQXMEJRj7aRAtLKfWmT6hH9V5AlgesUFMPODCR3SqgmyK9AcEG CaPUoak25qNEp/sRqRe9Vx8PXJTBvg0XndQOdfHrDUfdridZb57bxjSMHDXM+A0N0/QW W1d0xGXBdx/Dwy/oLX6e+GJcW14gxHeuIEG3PBbdR9gKAG/onBYqwbq8NzvBt9ZkHtJ0 2hYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=RVTUphdWuPLj7NAFJV+ZLCGO8w4s+kIPDL5af/SzqjM=; b=mcYsCBGy7nejZsoM+7YxmaijxlBVQYNQBAmF6B2lhKHiQLJ4fku3vCmC7tYfxA7Prq 3XBlWL9jyB6jwXhxjmfO5zxrHM42Fq4D9UgiIhRNPXjrOMjBiWXzpeAUtaOTu+TLGn0A ypXNxkZj03PnorlPXDl0FGPnWvjSbJH+KFWYAMRMCBRqbUAy6GaveAbC4c+i7ukJrFYX FyEhklo6d1HmqolNnOZ1BTeJRNEkyRfglhzAFVDHNkgURC1RCnhm9i5YXCLcz8qKsEgg bHJHjtc75AyhXuZ5mmBi5t64PbebhRgKedGws1wqRN3hrxCccGBaFD+/wjhWdquDJUDv wSLA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dlNwBS+u; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id c4si1191001pgu.355.2018.02.26.09.27.54; Mon, 26 Feb 2018 09:28:10 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dlNwBS+u; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1751857AbeBZR0f (ORCPT + 99 others); Mon, 26 Feb 2018 12:26:35 -0500 Received: from mail-qk0-f195.google.com ([209.85.220.195]:33516 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750842AbeBZR0c (ORCPT ); Mon, 26 Feb 2018 12:26:32 -0500 Received: by mail-qk0-f195.google.com with SMTP id f25so20008544qkm.0 for ; Mon, 26 Feb 2018 09:26:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RVTUphdWuPLj7NAFJV+ZLCGO8w4s+kIPDL5af/SzqjM=; b=dlNwBS+uhijKNL1tC6Eur/7mkXXD/tqwa3qNBFlg8zycsuQKXL+qvdwwXm7qGFybKv fG0gxxEGboxD3xKjotog1BW3g3i5Cce7hyzd4MHcwid1yMvUo6+fI6eIDV4wpHKh+7d7 jTxksu0AyyaqxlxrAFNUHKnn67OBDUKgb9hXqQJIUu4ac1/qfL7XYEnYk+JzlnlH3NO5 Bx1i+P9yCcIFNT++yFOGkcQBZZ0ArD//09Fg0LKKHBCvxJP4o1aKD11qw7K6iKKNkxUs cS1uRh3f3cARutlXlD4clLPRuabEDxH5ButZZ4M59tqj9CGLpRGkVKA/6wVkjVt6yVHX SWDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RVTUphdWuPLj7NAFJV+ZLCGO8w4s+kIPDL5af/SzqjM=; b=KO3YByx9+/s1IHw3Y6rNrokmmnsGly1q6ATkvAc/mK693Au2ECPPIa57fT3lzBeE4A yGLCruT1UK6+4/kwm/5q80SuYzswS8PIo6TbABX08DJysslh1bizDfioBPLha5ThgK2t Zu1UzxexpRshIw2Gm9jeJTWNzXfOSzizw8GkJoYQhnCI0zBYVyTglgTIUTfLChbG5hSk Z8IgsmbOOzV3P0rvRt5LRSMAk9hE625SL+oI+/fWG5XvFSNsUtDc/1vUW+LCM0x37JhX BwWlhx+R/K+YaKkKsR/eYSu7xSLVNSFoIBcsEMlfeUNmSNRsWpIx003yi17IlqsKyPIX uOWg== X-Gm-Message-State: APf1xPDHLt+TjlISXftiyWdfuYQg4Dj9VeRoAiIhmNCOhjN2rrb8w1YV mtrojKDgXThk3Xgv/2lxSbpvNYzvmxU5dWYuvvE= X-Received: by 10.55.88.7 with SMTP id m7mr18604016qkb.133.1519665991463; Mon, 26 Feb 2018 09:26:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.52.247 with HTTP; Mon, 26 Feb 2018 09:26:10 -0800 (PST) In-Reply-To: References: <9ec3c54c-f8fe-22d7-783e-8cf9862405bb@robertabel.eu> <20180225235432.31209-1-rabel@robertabel.eu> <20180225235432.31209-2-rabel@robertabel.eu> <20180225235432.31209-3-rabel@robertabel.eu> <20180225235432.31209-4-rabel@robertabel.eu> From: Miguel Ojeda Date: Mon, 26 Feb 2018 18:26:10 +0100 Message-ID: Subject: Re: [PATCH 3/4] auxdisplay: charlcd: fix x/y address commands To: Andy Shevchenko Cc: Robert Abel , linux-kernel , Willy Tarreau , Geert Uytterhoeven Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 26, 2018 at 6:09 PM, Andy Shevchenko wrote: > On Mon, Feb 26, 2018 at 6:54 PM, Miguel Ojeda > wrote: >> On Mon, Feb 26, 2018 at 12:44 PM, Andy Shevchenko >> wrote: >>> On Mon, Feb 26, 2018 at 1:54 AM, Robert Abel wrote: > >>>> + if ('x' == cmd) { >>>> + if (kstrtoul(esc, 10, &tmp_addr.x) < 0) >>>> break; >>> >>>> + } else if ('y' == cmd) { >>>> + if (kstrtoul(esc, 10, &tmp_addr.y) < 0) >>>> break; >>> >>> Perhaps instead of dancing around kstrtox() better to switch to >>> simple_strtoul() ? >> >> It seems deprecated: >> >> /* Obsolete, do not use. Use kstrto instead */ >> extern unsigned long simple_strtoul(const char *,char **,unsigned int); > > It has been discussed several times. The comment is simple wrong. > > Because of the requirement of kstrtox() to have a \0 or \n followed by > \0 as "end of field". > simple_strto*() is suitable to be run in place. I agree that in-place versions of these kind of string functions are very useful, don't get me wrong! But unless someone changes the "official" comment, we shouldn't add new code relying on them. > >>>> } >>>> + } >>> >>> Same indentation level or my mailer hides this from me? >> >> It is the same, but it is also how the other 'case's do it -- which in >> this case looks just wrong since it is the last one of the switch. I >> am not sure what is the preferred way of doing these kind of blocks, >> coding-style.rst does not seem to give an example for this case. > > Comes to my mind > - using }} > - putting default in between That is a clever one :-) But gcc complains, so we would need default + break, and that looks wrong as well. I would just move those two blocks into their own static function. The function is already long enough, specially with the new code. For small inside-switch blocks, I would just create the block at the level of the code, just like you would do inside functions. We can have another later patch to clean that up (and also the stuff below, which even has a TODO comment regarding it!). Cheers, Miguel > - ... ? > > -- > With Best Regards, > Andy Shevchenko