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] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 6 Jun 2008 07:50:37 +0200 (CEST)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	David Brownell <david-b@...bell.net>
cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC] generic GPIO parameter API

Hi David,

On Thu, 5 Jun 2008, David Brownell wrote:

> On Monday 02 June 2008, Guennadi Liakhovetski wrote:
> > Hi,
> > 
> > as far as I understand, the current GPIO API only presents very basic GPIO 
> > functionality: direction and level reading and writing. Whereas many GPIO 
> > controllers have many further configurable parameters: pull-ups and 
> > pull-downs, drive strength, slew rate, etc.
> 
> Not at all how I'd describe it.  Those omitted mechanisms are part
> of pin configuration, in the same way as function multiplexing is.
> (That is, assigning a given pin for use as a GPIO, vs hooking it up
> to an I2C, MMC, SPI, LCD, I2S, or memory controller.)
> 
> Those mechanisms are highly chip-specific.  Far more so than simple
> boolean GPIO mechanisms.  With rare exceptions, they're needed only
> in platform-specific board setup code, which is already accessing
> lots of platform-specific programming interfaces.  I'm really not
> keen on having them become part of the GPIO framework.  The thought
> makes me think of trying to swallow a kitchen sink; sorry ...

Thanks for the lengthy explanation with numerous examples - this is 
appreciated. But I'll omit that for this reply. Just a short question so 
far - how would you handle an external GPIO expander with an additional 
functionality, naimly, a possibility to switch pull-ups to GPIO pins, 
specifically, it defines 4 modes for a pin: out high, out low, in without 
a pullup and in with a pullup. And if the user application wants to decide 
at run-time which pull-ups to switch and when? It's a MAX7301 from Maxim 
btw.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ