Received: by 10.223.185.116 with SMTP id b49csp4302747wrg; Mon, 26 Feb 2018 15:08:58 -0800 (PST) X-Google-Smtp-Source: AH8x227PvdGimcKmgvQfXT9JlQe1uqJx5qCEKAFa9NDMlP0evwNdQqQPmfSuASRwaSuXHTOPXulw X-Received: by 2002:a17:902:2e04:: with SMTP id q4-v6mr12060421plb.22.1519686538556; Mon, 26 Feb 2018 15:08:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519686538; cv=none; d=google.com; s=arc-20160816; b=zfDg9l+WxbAhYLr1okbnQH3G24e0EDJDvXUCWdnA+TYO8t0mHmxdx6JSq9AmFrv80i OL+iqbUZUavGYcFpD3/a8StjFUMDDzMRbLJE5sxOlVm5EoVereZNZ6WbtFfoYYZRdKRV thw5HzBjzLoSp5TiyPfxf147SbKPOW7HSCmD8sYkGkoW8FSPFzpl5F63hskiiojESaI7 7DWglA02/tjr8C+kXStPh/4R4cuDxU0TkjHZJsg3t+zmIk2Ge2XcT7uectMsOSINyWnq zas2Kb+ldK7oZtUsaXjUKLG9L0OZuRI3xISSdam8UBDr+OIi+rGsDZnikjfaMC2qc/df 7IRA== 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=fqIQeTrjUfrUdRyke+ezoQkRriZGJKGE5gU4vAeSzzc=; b=n3psCgSib9lzLn9iXLRPqjBYMpEchIW5FsBFIK3Y6+1gFp0Gi9wuQBQ6e//dYLGD6l xr+PY6I9/Aa4zwwCYwNAEswURua6vIDJYYYSLEJCzZJ3OJDr8SbYrYfRaXkLjp+Obt6i fyW5DObeQ/X7jEcIOYgVJAxtxgS1k0SttDipZF0z6DtjpMOXNnBxkQ0hw/6mfMqtebZj oZd8xKhUgpORktPZc7cEFxhvPNeNs24e+39gAckWlfLkBrd2iLINvh2WFC+IeZZdXGS4 Q2CmnJbqhUm7fWY+V7vBNfLpxPPa6qGvd1oWLUyhEXVn1bFyQeIVHuMo1zNPhwE2/8LO y1xg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=h+GOgLUG; 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 e13si6093421pgu.821.2018.02.26.15.08.41; Mon, 26 Feb 2018 15:08:58 -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=h+GOgLUG; 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 S1751759AbeBZXG5 (ORCPT + 99 others); Mon, 26 Feb 2018 18:06:57 -0500 Received: from mail-qt0-f195.google.com ([209.85.216.195]:45021 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751550AbeBZXG4 (ORCPT ); Mon, 26 Feb 2018 18:06:56 -0500 Received: by mail-qt0-f195.google.com with SMTP id g60so20892713qtd.11 for ; Mon, 26 Feb 2018 15:06:55 -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=fqIQeTrjUfrUdRyke+ezoQkRriZGJKGE5gU4vAeSzzc=; b=h+GOgLUGs2FFijpKLR7nqQP1h331z3IYnDtwrJ/T92VAF1zux6DY1rrYEHo1oH/y17 GGc/TcXhLeivY0qHhN+yJEvm/i4m4dVKWZWDrwQYBYir/MzL/+lnFldsZibA+MH3qINd e9ZCpxJt/rLmYPIfZXfg94f7e9EfDhKLzLnk3FVak1Q86uw4Vve1ZpisTWxfOe2pRTod hVx1XDZJ4oTcMil0GvkCSS9zJSqwa1s9NtOAJWJdlPXdqKWZ2uGrOMl7BZJU5xn6ukTK MmT7NKhWkko8oTVxm1VUwbeYu3vt2DhNx7dAxYBIsAw/nQd/Z4RSUA1yszlJaF5wBAL1 9UhA== 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=fqIQeTrjUfrUdRyke+ezoQkRriZGJKGE5gU4vAeSzzc=; b=nd5hpEwImfOEutPEEv/GczGTrPNt1q9ofbCvmvhqdm/V7xtXA1PaP4UFpjxJEbQiPp osFTH34yS2J45ZSKcM+4cGthae23FX1L3F4w64a+gnL3WatQCc6gcgeiDuc40P7DxUEq ioolzv4t0AHhwLPw5B27H4FeMFuUYR70LJSshU30TbaBEiusTywNLXZB87o61grPIILO lc/w4wr3cqiSxytYw52BCPL5vLs9PrE1LNrpJ3lhtM4WZi8nUOoK7seyalw3P620UgQk K9eBMmyrJWveI7nYhGwggnT2DsvdaD6AdQAmVcBIodnEcu03j2IYTObYAC2cOvyQHTQL 2H9w== X-Gm-Message-State: APf1xPA67QMRI+G3EwtJoi4saoVh/uuIM9D2aC3ngphCFczI1G8hGv3x mfGuFKLkW7QPSpr0KCTB2dbMXvdCOw+WveXm6ec= X-Received: by 10.200.48.229 with SMTP id w34mr19921544qta.226.1519686415366; Mon, 26 Feb 2018 15:06:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.52.247 with HTTP; Mon, 26 Feb 2018 15:06:34 -0800 (PST) In-Reply-To: <48023798-595d-2a09-6f0c-2834ebefdd68@robertabel.eu> 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> <48023798-595d-2a09-6f0c-2834ebefdd68@robertabel.eu> From: Miguel Ojeda Date: Tue, 27 Feb 2018 00:06:34 +0100 Message-ID: Subject: Re: [PATCH 3/4] auxdisplay: charlcd: fix x/y address commands To: Robert Abel Cc: Andy Shevchenko , 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 11:38 PM, Robert Abel wrote: > Hi Andy, Hi Miguel, > > On 26 Feb 2018 12:44, Andy Shevchenko wrote: >> Can we avoid yoda style of programming? > On 26 Feb 2018 17:49, Miguel Ojeda wrote: >> Please do not change the style of the code w.r.t to the rest of the >> file, which writes tests with the non-lvalue on the right-hand side >> and do not compare against '\0'. Same for the rest. > > I am actually a fan of yoda-style programming, although its value is > diminished with modern IDEs, which we all use, right? The issue here is the consistency with the rest of the file (and with the vast majority of the kernel as well), not with the style in itself. If every single developer would write patches in their own style, everything would be a mess, so I can't accept a patch like that, sorry. In any case, most compilers warn in case of assignment (Wparentheses, which is on by default for the kernel), no need for a fancy IDE for this particular thing. :-) > > On 26 Feb 2018 17:54, Miguel Ojeda wrote: >> On Mon, Feb 26, 2018 at 12:44 PM, Andy Shevchenko >>> 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); > > I thought the whole point was that simple_strtoul is deprecated and on > the kill list? Isn't that kind of against the whole argument of > re-inventing the wheel? It is not about reinventing the wheel or not. Any internal kernel interface can change at any point -- which happens usually whenever someone comes up with a better way of doing things and others agree, specially if the benefits outweigh the risks/costs. > If using simple_strtoul is an option, it might be best to bring it back > and not touch the buffer at all. It isn't an option for me as a maintainer (unless there is really, really no better way of doing it), as long as we don't first agree (i.e. the kernel) what is obsoleted or not. Cheers, Miguel > > Regards, > > Robert