Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933082AbcK1OMC convert rfc822-to-8bit (ORCPT ); Mon, 28 Nov 2016 09:12:02 -0500 Received: from shards.monkeyblade.net ([184.105.139.130]:56732 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932283AbcK1OLx (ORCPT ); Mon, 28 Nov 2016 09:11:53 -0500 Date: Mon, 28 Nov 2016 09:11:49 -0500 (EST) Message-Id: <20161128.091149.2039527154584013771.davem@davemloft.net> To: nikita.yoush@cogentembedded.com Cc: fugang.duan@nxp.com, troy.kisky@boundarydevices.com, andrew@lunn.ch, eric@nelint.com, tremyfr@gmail.com, johannes@sipsolutions.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, cphealy@gmail.com, fabio.estevam@nxp.com Subject: Re: [PATCH] net: fec: turn on device when extracting statistics From: David Miller In-Reply-To: <4ddb5842-0ece-2950-214f-f56db808ffbd@cogentembedded.com> References: <1480068120-22137-1-git-send-email-nikita.yoush@cogentembedded.com> <20161127.202945.1759992980026862076.davem@davemloft.net> <4ddb5842-0ece-2950-214f-f56db808ffbd@cogentembedded.com> X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=koi8-r Content-Transfer-Encoding: 8BIT X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Mon, 28 Nov 2016 05:12:28 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1166 Lines: 32 From: Nikita Yushchenko Date: Mon, 28 Nov 2016 10:06:31 +0300 > > > 28.11.2016 04:29, David Miller ?????: >> From: Nikita Yushchenko >> Date: Fri, 25 Nov 2016 13:02:00 +0300 >> >>> + int i, ret; >>> + >>> + ret = pm_runtime_get_sync(&fep->pdev->dev); >>> + if (IS_ERR_VALUE(ret)) { >>> + memset(data, 0, sizeof(*data) * ARRAY_SIZE(fec_stats)); >>> + return; >>> + } >> >> This really isn't the way to do this. >> >> When the device is suspended and the clocks are going to be stopped, >> you must fetch the statistic values into a software copy and provide >> those if the device is suspended when statistics are requested. > > Ok, can do that, although can't see what's wrong with waking device > here. The situation of requesting stats on down device isn't something > widely used, thus keeping handling of that as local as possible looks > better for me. The issue is the fact that you need error handling at all and might therefore provide a set of zero stats to the user when that entire possibility could have been avoided in the first place by recording the stats at suspend time.