linux-kernel - Re: [patch/rfc 1/4] GPIO implementation framework

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:	Tue, 13 Nov 2007 23:08:47 -0800
From:	David Brownell <david-b@...bell.net>
To:	"eric miao" <eric.y.miao@...il.com>
Cc:	"Linux Kernel list" <linux-kernel@...r.kernel.org>,
	"Felipe Balbi" <felipebalbi@...rs.sourceforge.net>,
	"Bill Gatliff" <bgat@...lgatliff.com>,
	"Haavard Skinnemoen" <hskinnemoen@...el.com>,
	"Andrew Victor" <andrew@...people.com>,
	"Tony Lindgren" <tony@...mide.com>,
	"Jean Delvare" <khali@...ux-fr.org>,
	"Kevin Hilman" <khilman@...sta.com>,
	"Paul Mundt" <lethal@...ux-sh.org>,
	"Ben Dooks" <ben@...nity.fluff.org>
Subject: Re: [patch/rfc 1/4] GPIO implementation framework

On Tuesday 13 November 2007, eric miao wrote:
> > > > We "can" do most anything. What would that improve though?
> >
> > ... What would that improve, though?  Your followup posts
> > still don't answer that question for me.  I see the code,
> > but don't have an answer to that question.
> >
> 
> to be honest, I don't feel like the holes. Put restrictions on
> the numbering of GPIOs might not be a good idea either.

So the point of these is to make it easier for platforms
(or even just boards) to make sure the GPIO number space
is densely packed, rather than loosely so?  Paying about
2KBytes for that privilege.  (Assuming a 32 bit system
with 256 GPIOs.)

I could see that being a reasonable tradeoff.  I wouldn't
have started there myself, but you know how that goes!

Does anyone else have any comments on that issue?

One point you haven't really brought up in this thread is
your concern about the impact of this on IRQs.  One issue
being that for GPIOs used as IRQs, with linear mappings
resembling

	static inline int gpio_to_irq(unsigned gpio)
	{
		if (gpio >= LAST_IRQ_CAPABLE_GPIO)
			return -EINVAL;
		return irq + FIRST_GPIO_IRQ_NUMBER;
	}

then tightly packed GPIOs mean less space wasted for IRQ
descriptors that would never be used.

And since an irq_desc bigger than your gpio_desc, there's
a tradeoff between wasting space on unused gpio_desc structs
versus unused irq_desc structs.  2 KBytes would cost about
only 35 irq_desc structs, vs 256 gpio_desc structs.

I'm guessing that's why you care about dense packing for
the GPIO numbers...

- Dave

-
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/