Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755201Ab1DTPR6 (ORCPT ); Wed, 20 Apr 2011 11:17:58 -0400 Received: from mail-wy0-f174.google.com ([74.125.82.174]:40379 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754725Ab1DTPR4 (ORCPT ); Wed, 20 Apr 2011 11:17:56 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Z0fG9V4WqiOjLBxP6Dm2vwJyA0vI4AumceYPkpEJITG0gm3YzjhV9c2/cSrJQESdUm /HmXgw2l9CaW4NLjxLmsb3a+n4D5P0VpZkg83/bpQEEuUn5HB7CtQ+mhsRT8eoYAiKRz 1gKZjjmekpkiluifm0B3gZC913YjJzDImNCiA= MIME-Version: 1.0 In-Reply-To: References: <1303076273-8093-1-git-send-email-linus.walleij@stericsson.com> <3F5641E3-C443-4541-9FDA-24D215597C1F@niasdigital.com> <20110418091902.13345132@lxorguk.ukuu.org.uk> <92FFDB9F-37F1-4618-A53D-FEF4151A4953@niasdigital.com> <20110418132629.12d9a106@lxorguk.ukuu.org.uk> <6C3F739A-A157-4796-9572-C6B0FAC2565E@niasdigital.com> <20110419093855.36910400@lxorguk.ukuu.org.uk> Date: Wed, 20 Apr 2011 17:17:55 +0200 X-Google-Sender-Auth: LzK5nCh1L-_IhYyJJyX04nb6grM Message-ID: Subject: Re: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib From: Linus Walleij To: Haojian Zhuang Cc: Kyungmin Park , linux-kernel@vger.kernel.org, Grant Likely , linux-arm-kernel@lists.infradead.org, Ben Nizette , Lee Jones , Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1012 Lines: 26 2011/4/20 Haojian Zhuang : > I have an another question on board initialization. The configuration on pins > are including drive strength, pull and multiple function. > > Since this patch can configure drive strength, pull. Will it be preferred to use > in board initialization? I am reusing it (inside the example driver) for drive strength and bias. Multiple function again is pin/padmuxing. Even if some people are only muxing pins that can also be used as GPIO, this is not always the case. We can shunt out the same pins to be used as I2C or SPI for example, that means this cannot be handled in a GPIO driver since it has nothing to do with GPIO pins at all. Thus we need an orthogonal pin/padmux mechanism. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/