Return-path: Received: from comal.ext.ti.com ([198.47.26.152]:38292 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752374Ab0ISMX3 convert rfc822-to-8bit (ORCPT ); Sun, 19 Sep 2010 08:23:29 -0400 From: "Levi, Shahar" To: Julian Calaby CC: Luciano Coelho , "linux-wireless@vger.kernel.org" Date: Sun, 19 Sep 2010 14:23:21 +0200 Subject: RE: [PATCH 04/04] wl1271: 11n Support, 11n Kconfig Configurable Message-ID: References: <1284575472-19888-1-git-send-email-shahar_levi@ti.com> <1284575472-19888-5-git-send-email-shahar_levi@ti.com> <1284578468.1569.29.camel@powerslave> In-Reply-To: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: > -----Original Message----- > From: Julian Calaby [mailto:julian.calaby@gmail.com] > Sent: Sunday, September 19, 2010 3:19 AM > To: Levi, Shahar > Cc: Luciano Coelho; linux-wireless@vger.kernel.org > Subject: Re: [PATCH 04/04] wl1271: 11n Support, 11n Kconfig Configurable > > Unless people dislike your patches, there's no danger that they won't > all be applied to the kernel. > > That said, there are still circumstances when only part of a patch > series like your one will be applied to a kernel. One of these is when > a user is using git bisection to find exactly which commit caused a > particular bug. > > So, let's say you upgrade your kernel from 2.6.35 to 2.6.38 and your > wl1271 device now won't connect to an AP running on some random > proprietary hardware. The simplest way to determine exactly which > patch caused this issue is to use git bisect to do a binary search > over the changes between these two kernel versions to determine the > exact patch that broke it. Now, let's assume that, this particular > piece of hardware won't connect to *anything* when 802.11n support is > added, so you've already excluded that from your kernel. If git bisect > decides to leap into the middle of your series, so that 802.11n > support is added before the Kconfig option is added, then 802.11n > support will be unconditionally enabled, and you'll see the symptoms > of that bug, and won't be able to quickly determine whether the bug > existed before the 802.11n patches or after, and git bisect might > wrongly assume that these patches were the cause of the bug. > > As such, it's generally regarded as a good idea to introduce Kconfig > options with the code they guard. > > Thanks, > > -- > > Julian Calaby > > Email: julian.calaby@gmail.com > Profile: http://www.google.com/profiles/julian.calaby/ > .Plan: http://sites.google.com/site/juliancalaby/ Hi Julian, You are right. I will squash 3 and 4 into one patch in v2. I greatly appreciate your elaboration and help to understand. Thanks you, Shahar