linux-kernel - Re: [PATCH 10/13] tty: serial: omap: remove some dead code

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 23 Apr 2014 20:43:34 -0500
From:	Felipe Balbi <balbi@...com>
To:	NeilBrown <neilb@...e.de>
CC:	<balbi@...com>, Nishanth Menon <nm@...com>,
	Greg KH <gregkh@...uxfoundation.org>, <marcel@...tmann.org>,
	<gustavo@...ovan.org>, <johan.hedberg@...il.com>, <jslaby@...e.cz>,
	<grant.likely@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	<linux-bluetooth@...r.kernel.org>, <linux-serial@...r.kernel.org>,
	<devicetree@...r.kernel.org>,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH 10/13] tty: serial: omap: remove some dead code

Hi,

On Thu, Apr 24, 2014 at 11:41:15AM +1000, NeilBrown wrote:
> On Wed, 23 Apr 2014 20:21:00 -0500 Felipe Balbi <balbi@...com> wrote:
> 
> > I have no problem either way, just that unused code doesn't have to be
> > sitting in the tree and I'm not entirely sure this GPIO should be
> > handled by omap-serial.c, perhaps something more generic inside
> > serial-core so other UART drivers can benefit from it.
> 
> Perhaps.  But there there are more people I need to convince :-)

heh, Greg is in Cc, that'd be a good start.

> > > On the other hand, if you can point out to me what I'm missing, and how I can
> > > solve my problem with any virtual GPIOs, I'm all ears.
> > > 
> > > To make my problem simple and explicit:  I have a device attached to a UART
> > > which has a separate regulator.  The regulator should be powered on if and
> > 
> > So you're using DTR to power the GPIO and hoping that the regulator
> > stabilizes quickly enough so that by the time your open() finishes you
> > don't have to add nonsensical msleep() calls before writing to the
> > device. Sounds a bit fragile to me.
> 
> The gpio_set call is synchronous, and the gpio-regulator driver could add a

sure, but it's synchronous towards toggling the GPIO, pulling it high.
It doesn't guarantee that the far-end regulator's output will be fully
changed.

> delay (I think).

yeah, that'd be part of the regulator-gpio with the startup-delay-ns
property (IIRC)

> > > only if the /dev/ttyXX interface to the UART is open.  The device is a
> > > bluetooth transceiver.
> > 
> > considering this is a BTUART device, why didn't you do this at the ldisc
> > level ? hci_uart_open() sounds like a good choice from a quick thinking.
> > 
> 
> I'll have a look into that, thanks.

so, Ack for $subject or not ?

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)