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;
Date:   Wed, 7 Jul 2021 21:52:05 +0200
From:   Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= <kw@linux.com>
To:     Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc:     thierry.reding@gmail.com, lorenzo.pieralisi@arm.com,
        robh@kernel.org, bhelgaas@google.com, jonathanh@nvidia.com,
        linux-tegra@vger.kernel.org, linux-pci@vger.kernel.org,
        linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 3/3] PCI: tegra: make const array err_msg static
Message-ID: <20210707195205.GA6952@rocinante>
References: <55b11e9a7fa2987fbc0869d68ae59888954d65e2.1620148539.git.christophe.jaillet@wanadoo.fr>
 <5f3f35296b944b94546cc7d1e9cc6186484620d8.1620148539.git.christophe.jaillet@wanadoo.fr>
 <20210705223152.GA142312@rocinante>
 <a3d48884-9e47-8623-6fc5-6c52f4ca0568@wanadoo.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <a3d48884-9e47-8623-6fc5-6c52f4ca0568@wanadoo.fr>
Precedence: bulk

Hi Christophe,

[...]
> > These should be trivial to fix.  The two pertaining to "quoted string
> > split across lines" would be something that we might or might not decide
> > to do anything about this - technically, as per the Linux kernel coding
> > style [1], we ought to fix this... but, this particular case is not
> > a terrible example, so I will leave this at your discretion.
> > 
> > What do you think?
> 
> Hi,
> I don't think it worth it.
> 
> Even for patch 2/3 about 'seq_printf' --> 'seq_puts' conversion, I'm not
> fully convinced myself that is useful.

I personally believe it's a good change.

For a literal string without any formatting using the seq_printf() is
much more involved for no reason, but aside of this small performance
improvement, it also has some value in demonstrating the correct usage
patterns - people spent more time reading kernel code and looking at how
to do things and use things to base their work on, so setting some
example is not a bad idea.

Albeit, it's a matter of point of view too, I suppose.

> Too trivial clean-ups only mess-up 'git blame' for no real added value.

Yes, there is a fine line with these.

> If you want these clean-ups, I can send a patch for it, but checkpatch
> output need sometimes to be ignored on files already in the tree. At least,
> this is my point of view.

No worries!  Thank you for giving it some thought!  I appreciate it. :)

	Krzysztof