linux-kernel - Re: [PATCH 2/2] at91/USB: at91sam9g45 series USB host integration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4ABA3F54.3020600@atmel.com>
Date:	Wed, 23 Sep 2009 17:31:32 +0200
From:	Nicolas Ferre <nicolas.ferre@...el.com>
To:	Andrew Victor <avictor.za@...il.com>
CC:	David Brownell <david-b@...bell.net>,
	Haavard Skinnemoen <haavard.skinnemoen@...el.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	patrice.vilchez@...el.com
Subject: Re: [PATCH 2/2] at91/USB: at91sam9g45 series USB host integration

Andrew Victor :
> hi David,
> 
>> On Friday 19 June 2009, Haavard Skinnemoen wrote:
>>> David Brownell wrote:
>>>>> --- a/arch/arm/mach-at91/at91sam9g45_devices.c
>>>>> +++ b/arch/arm/mach-at91/at91sam9g45_devices.c
>>>>> + /* Enable VBus control for UHP ports */
>>>>> + for (i = 0; i < data->ports; i++) {
>>>>> +         if (data->vbus_pin[i])
>>>>> +                 at91_set_gpio_output(data->vbus_pin[i], 0);
>>>> This should gpio_request() and gpio_direction_output().
>>> Hmm...I thought the driver was supposed to call gpio_request(), not the
>>> platform code?
>> In some cases.  This isn't a good case for that.  Especially
>> if it's going to call gpio_direction_output() ... which needs
>> gpio_request() to have been done first.
> 
> I have to agree with Haavard on this - it's really not clear if
> gpio_request() should be called in the platform-code or in the driver.
> 
> If the platform code performs a gpio_request() then surely it needs to
> call a gpio_free() after configuring the pin.
> Otherwise the driver's initialization code performs another
> gpio_request() for that pin, but it is still "in-use" by the platform
> code.
> 
> Also Documentation/gpio.txt doesn't say if a GPIO pin should even
> retain it's configured state across after a gpio_free().
> 
> 
> So for the core AT91 platform code, I'd continue to use the
> AT91-specific GPIO configuration functions.
> The drivers should perform the gpio_request() / gpio_free(), and it
> can still call gpio_direction_output() if necessary.

Fair enough. So I forget my gpiolib patch on top of the former USB
integration one.

With your Ack, I will publish it to Russell's patch tracking system...

Bye,
-- 
Nicolas Ferre

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/