From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757205AbcLOBOR (ORCPT ); Wed, 14 Dec 2016 20:14:17 -0500 Received: from 92-243-34-74.adsl.nanet.at ([92.243.34.74]:52070 "EHLO mail.osadl.at" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1757173AbcLOBOP (ORCPT ); Wed, 14 Dec 2016 20:14:15 -0500 Date: Thu, 15 Dec 2016 01:14:05 +0000 From: Nicholas Mc Guire To: Sylwester Nawrocki Cc: Laurent Pinchart , Nicholas Mc Guire , Mauro Carvalho Chehab , Sakari Ailus , Hans Verkuil , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC] [media] s5k6aa: set usleep_range greater 0 Message-ID: <20161215011405.GB22190@osadl.at> References: <1481594282-12801-1-git-send-email-hofrat@osadl.org> <5277658.1FioEDcST1@avalon> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 13, 2016 at 03:53:47PM +0100, Sylwester Nawrocki wrote: > Hi Laurent, > > On 12/13/2016 03:10 PM, Laurent Pinchart wrote: > > As pointed out by Ian Arkver, the datasheet states the delay should be >50µs. > > Would it make sense to reduce the sleep duration to (3000, 4000) for instance > > (or possibly even lower), instead of increasing it ? > > Theoretically it would make sense, I believe the delay call should really > be part of the set_power callback. I think it is safe to decrease the > delay value now, the boards using that driver have been dropped with commit > > commit ca9143501c30a2ce5886757961408488fac2bb4c > ARM: EXYNOS: Remove unused board files > > As far as I am concerned you can do whatever you want with that delay > call, remove it or decrease value, whatever helps to stop triggering > warnings from the static analysis tools. > if its actually unused then it might be best to completely drop the code raher than fixing up dead-code. Is the EXYNOS the only system that had this device in use ? If it shold stay in then setting it to the above proposed 3000, 4000 would seem the most resonable to me as I asume this change would stay untested. thx! hofrat