From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932489Ab2DNAp5 (ORCPT ); Fri, 13 Apr 2012 20:45:57 -0400 Received: from shards.monkeyblade.net ([198.137.202.13]:54141 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757378Ab2DNApz (ORCPT ); Fri, 13 Apr 2012 20:45:55 -0400 Date: Fri, 13 Apr 2012 20:45:51 -0400 (EDT) Message-Id: <20120413.204551.959091962456153270.davem@davemloft.net> To: xiong@qca.qualcomm.com Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, qca-linux-team@qualcomm.com, nic-devel@qualcomm.com Subject: Re: [PATCH 04/37] atl1c: remove VPD register From: David Miller In-Reply-To: <1334276102-15866-5-git-send-email-xiong@qca.qualcomm.com> References: <1334276102-15866-1-git-send-email-xiong@qca.qualcomm.com> <1334276102-15866-5-git-send-email-xiong@qca.qualcomm.com> X-Mailer: Mew version 6.4 on Emacs 24.0.95 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (shards.monkeyblade.net [198.137.202.13]); Fri, 13 Apr 2012 17:45:54 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: xiong Date: Fri, 13 Apr 2012 08:14:29 +0800 > VPD register is only used for L1(devid=PCI_DEVICE_ID_ATTANSIC_L1) to > access external NV-memory. > l1c & later chip doesn't use it any more. > > Signed-off-by: xiong > Tested-by: Liu David You just broke ethtool register dumps with this change. Now, all the initial registers are reported offset by one entry, yet the last two are still reported in their original spots. This layout is exposed to userspace, and interpreted by tools, and you cannot change it. If this register always reports some value, you should just keep it there in the dumps. I think you guys are way too aggressively removing things from the driver. You are also posting way too many patches at one time. If you post so many patches at once, if one of the early patches have a problem (as already is the case here) it means all the rest of your patches will not apply without offsets or rejects and therefore will all need to be redone and resubmitted. Posting too many patches at once also creates a large burdon for those who will choose to help review your changes. Send a small, reasonable, number of patches at one time. Say, for example, 10 or 15 maximum.