From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752564Ab1AXUO5 (ORCPT ); Mon, 24 Jan 2011 15:14:57 -0500 Received: from mail-ey0-f174.google.com ([209.85.215.174]:34221 "EHLO mail-ey0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752487Ab1AXUOz (ORCPT ); Mon, 24 Jan 2011 15:14:55 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=bFcVq0BkDwW+FhfSRFB+f86K5ME+WDdrimgWXIKaNoqLqSg3ynsPD6Qb4CAceqD0za 3z/vPoY+aHGofl7lV6fkPWZTKwkIrWGDHi+RUlDLxo6Z6FGWLDHefdmXMeEArwPCSjUL /GmFYoDks8+hliaR9N7M5acVDWTtUZ28az9D8= Date: Mon, 24 Jan 2011 23:14:48 +0300 From: Vasiliy Kulikov To: Julia Lawall Cc: Ryan Mallon , Russell King , kernel-janitors@vger.kernel.org, Nicolas Ferre , Jean-Christophe PLAGNIOL-VILLARD , Andrew Victor , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test Message-ID: <20110124201447.GA31162@albatros> References: <1295898922-18822-1-git-send-email-julia@diku.dk> <1295898922-18822-3-git-send-email-julia@diku.dk> <4D3DD964.9020107@bluewatersys.com> <20110124200515.GA30963@albatros> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 24, 2011 at 21:09 +0100, Julia Lawall wrote: > On Mon, 24 Jan 2011, Vasiliy Kulikov wrote: > > clk_get() is defined per-architecture, sometimes it is NULL only. > > In this case there is a definition in the same file, so it doesn't seem > necessary to worry about possible other ones. Unless there is some goal > in the future to remove the local one? My oppinion is that even such architecture dependent code written in architecure indepenent way is highly desirable. Besides more clean code it is probably review by smaller group of people, so it is potentially more buggy. Thanks, -- Vasiliy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vasiliy Kulikov Date: Mon, 24 Jan 2011 20:14:48 +0000 Subject: Re: [PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test Message-Id: <20110124201447.GA31162@albatros> List-Id: References: <1295898922-18822-1-git-send-email-julia@diku.dk> <1295898922-18822-3-git-send-email-julia@diku.dk> <4D3DD964.9020107@bluewatersys.com> <20110124200515.GA30963@albatros> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On Mon, Jan 24, 2011 at 21:09 +0100, Julia Lawall wrote: > On Mon, 24 Jan 2011, Vasiliy Kulikov wrote: > > clk_get() is defined per-architecture, sometimes it is NULL only. > > In this case there is a definition in the same file, so it doesn't seem > necessary to worry about possible other ones. Unless there is some goal > in the future to remove the local one? My oppinion is that even such architecture dependent code written in architecure indepenent way is highly desirable. Besides more clean code it is probably review by smaller group of people, so it is potentially more buggy. Thanks, -- Vasiliy From mboxrd@z Thu Jan 1 00:00:00 1970 From: segooon@gmail.com (Vasiliy Kulikov) Date: Mon, 24 Jan 2011 23:14:48 +0300 Subject: [PATCH 2/4] arch/arm/mach-at91/clock.c: Add missing IS_ERR test In-Reply-To: References: <1295898922-18822-1-git-send-email-julia@diku.dk> <1295898922-18822-3-git-send-email-julia@diku.dk> <4D3DD964.9020107@bluewatersys.com> <20110124200515.GA30963@albatros> Message-ID: <20110124201447.GA31162@albatros> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Jan 24, 2011 at 21:09 +0100, Julia Lawall wrote: > On Mon, 24 Jan 2011, Vasiliy Kulikov wrote: > > clk_get() is defined per-architecture, sometimes it is NULL only. > > In this case there is a definition in the same file, so it doesn't seem > necessary to worry about possible other ones. Unless there is some goal > in the future to remove the local one? My oppinion is that even such architecture dependent code written in architecure indepenent way is highly desirable. Besides more clean code it is probably review by smaller group of people, so it is potentially more buggy. Thanks, -- Vasiliy