From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753384AbdJSMEL (ORCPT ); Thu, 19 Oct 2017 08:04:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:54595 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752845AbdJSMEJ (ORCPT ); Thu, 19 Oct 2017 08:04:09 -0400 Date: Thu, 19 Oct 2017 14:04:06 +0200 From: Michal =?UTF-8?B?U3VjaMOhbmVr?= To: Andy Shevchenko Cc: SF Markus Elfring , Jarkko Sakkinen , linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Stefan Berger , Alexander Steffen , Nayna Jain , kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, Jerry Snitselaar , Jason Gunthorpe , Julia Lawall , Corentin Labbe , Kenneth Goldman , Paul Mackerras , Peter =?UTF-8?B?SMO8d2U=?= , Mimi Zohar Subject: Re: char/tpm: Improve a size determination in nine functions Message-ID: <20171019140406.046d2714@kitsune.suse.cz> In-Reply-To: <1508349793.16112.507.camel@linux.intel.com> References: <1508238182.16112.475.camel@linux.intel.com> <1508244757.4234.60.camel@linux.vnet.ibm.com> <1508253453.4234.81.camel@linux.vnet.ibm.com> <9689f036-ba9f-d23b-cf89-c289bc308771@users.sourceforge.net> <20171018145735.lpzwakatsty7emlw@linux.intel.com> <351cf78a-14f6-c6e7-2902-048e7dc57a14@users.sourceforge.net> <20171018155946.e7ga7jyex6eia252@linux.intel.com> <55d76224-3019-6614-70ce-ba260bbcd54f@users.sourceforge.net> <20171018171858.3lcfr2kcp53fngwv@linux.intel.com> <1508349793.16112.507.camel@linux.intel.com> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 18 Oct 2017 21:03:13 +0300 Andy Shevchenko wrote: > On Wed, 2017-10-18 at 19:48 +0200, SF Markus Elfring wrote: > > > For 1/4 and 2/4: explain why the message can be omitted. > > > > That's all. > > > > I assume that there might be also some communication challenges > > involved. > > > > > > > 3/4: definitive NAK, too much noise compared to value. > > > > I tried to reduce deviations from the Linux coding style again. > > You do not like such an attempt for this software area so far. > > The problem here in a time line or what comes first. Definitely, you > are trying to fix the code which _is_ upstream vs. the code which > _might be_ upstream (exception is drivers/staging). > > Why didn't you listen to what people are telling you? > > Why are you spending too much time on little sense crap instead of > doing real fixes? > People are free to spend their time on what they like. Even if no commit of this series lands in mainline it has been useful to clarify what is preferred style and what is useful fix. Thanks Michal