From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753584AbaCKKI1 (ORCPT ); Tue, 11 Mar 2014 06:08:27 -0400 Received: from mail-ee0-f49.google.com ([74.125.83.49]:59114 "EHLO mail-ee0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752014AbaCKKIZ (ORCPT ); Tue, 11 Mar 2014 06:08:25 -0400 Date: Tue, 11 Mar 2014 11:08:19 +0100 From: Richard Cochran To: Christian Riesch Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Ben Hutchings , David Miller , Stefan =?iso-8859-1?Q?S=F8rensen?= Subject: Re: [PATCH RFC net-next v1 1/9] ptp: introduce programmable pins. Message-ID: <20140311100818.GA4266@netboy> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue, Mar 11, 2014 at 08:58:45AM +0100, Christian Riesch wrote: > >+ if (pin1 && pin1->func == PTP_PF_PHYSYNC) { > >+ pr_err("sorry, cannot reprogram the calibration pin\n"); > >+ return -EINVAL; > > ^^^^ > Will this ever happen? pin1 && pin1->func == PTP_PF_PHYSYNC means > that func == PTP_PF_PHYSYNC, but in this case you already return > -EINVAL a few lines above. This a bug. I really meant to test (pin2->func == PTP_PF_PHYSYNC) to prevent clobbering the calibration function with some other function. I'll fix it for v2. Thanks, Richard