From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752293AbbCYFHr (ORCPT ); Wed, 25 Mar 2015 01:07:47 -0400 Received: from mail-pd0-f174.google.com ([209.85.192.174]:33240 "EHLO mail-pd0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750802AbbCYFHn (ORCPT ); Wed, 25 Mar 2015 01:07:43 -0400 Date: Wed, 25 Mar 2015 10:37:32 +0530 From: Sudip Mukherjee To: Willy Tarreau Cc: Greg Kroah-Hartman , devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2 2/2] staging: panel: fix lcd type in module parameters Message-ID: <20150325050732.GA4004@sudip-PC> References: <1427189193-7984-1-git-send-email-sudipm.mukherjee@gmail.com> <1427189193-7984-2-git-send-email-sudipm.mukherjee@gmail.com> <20150324232559.GA23298@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150324232559.GA23298@1wt.eu> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 25, 2015 at 12:25:59AM +0100, Willy Tarreau wrote: > On Tue, Mar 24, 2015 at 02:56:33PM +0530, Sudip Mukherjee wrote: > > with reference to the previous patch of the series, fixed the > > lcd type in module parameters. > > Sudip, it's better to avoid fragmenting patches like you did, because > it will result in a kernel state where there is an inconsistency between > the parameters actually used by the kernel and those reported by modinfo. > This can happen for example if someone does a bisect and ends up on patch > 1/2 applied only. Obviously in this case there is very little harm, but > you get the idea : each patch should be a functional change, address one > thing and do it consistently. So if you change the #defines or enums or > whatever, all the locations where their old values were referenced must > be changed in the same patch, simply because in fact they are duplicate > entries. Another point is that someone who notices your patch v1 and > does not notice patch v2 could pick v1 for his kernel and end up with > something inconsistent. For this reason it would be better to merge your > patches into a single one here. explained very well. thanks. i was wondering why Dan asked me to merge them into one. regards sudip > > > might not apply properly to old versions, some reordering was done > > in commit <98e0e762e> > > Appreciated, thanks for checking this! > > Best regards, > Willy >