From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934823AbcKMRj6 (ORCPT ); Sun, 13 Nov 2016 12:39:58 -0500 Received: from shards.monkeyblade.net ([184.105.139.130]:44382 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753258AbcKMRj4 (ORCPT ); Sun, 13 Nov 2016 12:39:56 -0500 Date: Sun, 13 Nov 2016 12:39:54 -0500 (EST) Message-Id: <20161113.123954.2134945576362221851.davem@davemloft.net> To: hayeswang@realtek.com Cc: netdev@vger.kernel.org, nic_swsd@realtek.com, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, mlord@pobox.com Subject: Re: [PATCH net 2/2] r8152: rx descriptor check From: David Miller In-Reply-To: <1394712342-15778-228-Taiwan-albertk@realtek.com> References: <1394712342-15778-226-Taiwan-albertk@realtek.com> <1394712342-15778-228-Taiwan-albertk@realtek.com> X-Mailer: Mew version 6.7 on Emacs 25.1 / 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.5.12 (shards.monkeyblade.net [149.20.54.216]); Sun, 13 Nov 2016 08:40:26 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Hayes Wang Date: Fri, 11 Nov 2016 15:15:41 +0800 > For some platforms, the data in memory is not the same with the one > from the device. That is, the data of memory is unbelievable. The > check is used to find out this situation. > > Signed-off-by: Hayes Wang I'm all for adding consistency checks, but I disagree with proceeding in this manner for this. If you add this patch now, there is a much smaller likelyhood that you will work with a high priority to figure out _why_ this is happening. For all we know this could be a platform bug in the DMA API for the systems in question. It could also be a bug elsewhere in the driver, either in setting up the descriptor DMA mappings or how the chip is programmed. Either way the true cause must be found before we start throwing changes like this into the driver. I'm not applying this series, sorry.