From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752273AbeAERZw (ORCPT + 1 other); Fri, 5 Jan 2018 12:25:52 -0500 Received: from mga02.intel.com ([134.134.136.20]:3199 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751888AbeAERZv (ORCPT ); Fri, 5 Jan 2018 12:25:51 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,319,1511856000"; d="scan'208";a="7757622" Message-ID: <1515172696.7000.754.camel@linux.intel.com> Subject: Re: [PATCH v2] x86/platform/intel-mid: Revert "Make 'bt_sfi_data' const" From: Andy Shevchenko To: Ingo Molnar , Fengguang Wu Cc: Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , x86@kernel.org, Andi Kleen , linux-kernel@vger.kernel.org, Darren Hart , platform-driver-x86@vger.kernel.org, Bhumika Goyal , julia.lawall@lip6.fr Date: Fri, 05 Jan 2018 19:18:16 +0200 In-Reply-To: <20171228123413.3shmkfsewmq3y4e5@gmail.com> References: <20171228122523.21802-1-andriy.shevchenko@linux.intel.com> <20171228123413.3shmkfsewmq3y4e5@gmail.com> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, 2017-12-28 at 13:34 +0100, Ingo Molnar wrote: > * Andy Shevchenko wrote: > > > v2: low the tone of accusation that this made a regression > > BTW., don't worry about that aspect too much: after a long debugging > session it's > pretty natural to be upset at whoever introduced a regression. It appears that regression has been introduced by a new dependency to the hci_bcm.c. In any case, can we apply this one to 4.15 cycle to make others prevent do an actual regressions further: commit 03838ae1e8f692dd2bdbd49820ed668d4b7bfbc2 Author: Andi Kleen Date: Fri Jan 5 13:26:44 2018 +1100 arch/x86/platform/intel-mid/device_libs/platform_bt.c: fix const confusion > > ( In fact a number of times I too got upset at the moron who wrote a > particular > piece of buggy code, only for 'git annotate' to remind me that the > moron was me. ) > > I personally just ignore the emotional attributes, and I usually edit > changelogs > accordingly as well so the temporary state of mind of finding a > regression doesn't > trickle upstream. > > Plus in this particular case if we can help type propagation for > driver data to > become a bit cleaner then the kernel project has gained a bit through > all this > pain. I has been thinking if 0day can complain about these: 1) castings in new code 2) applying const to older *working* code Fengguang, what do you think? -- Andy Shevchenko Intel Finland Oy