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, 03 Jan 2012 17:27:13 +0900
From:	Chanho Park <chanho61.park@...sung.com>
To:	'Linus Walleij' <linus.walleij@...aro.org>
Cc:	swarren@...dia.com, Baohua.Song@....com,
	linux-kernel@...r.kernel.org
Subject: RE: [PATCH 0/2] add support for partial pin space

Hello Linus W.,
Original code always enumerate from 0 to maxpin because you wrote
as an offset equals to a pin number. It's inefficient because we always
define and enumerate whole pins in the system even though we do not use
the pin.
The pin space was already stored as array in the pin controller descriptor.
And we also have a number of pins.

Please see below example,

static const struct pinctrl_pin_desc pads[] = {
	PINCTRL_PIN(100, "PIN100"),
	PINCTRL_PIN(9999, "PIN9999"),
};
In this extreme system, the system has two pins.
We do not support non-zero based pin starting number.
And we always do silly loop until 0 to 9999. :)

This patch enables to enumerate the pin space by using the offset of array.
Thus, we don't need maxpin to enumerate the pin space because it is
sufficient
to use npins.

Best Regards,
Chanho Park


> -----Original Message-----
> From: Linus Walleij [mailto:linus.walleij@...aro.org]
> Sent: Tuesday, January 03, 2012 4:57 PM
> To: Chanho Park
> Cc: swarren@...dia.com; Baohua.Song@....com; linux-
> kernel@...r.kernel.org
> Subject: Re: [PATCH 0/2] add support for partial pin space
> 
> On Tue, Jan 3, 2012 at 8:47 AM, Chanho Park <chanho61.park@...sung.com>
> wrote:
> 
> > A pin space of current pinctrl driver always start with zero-based
> pin
> > number. And pins are enumerated from 0 to a max pin number. If there
> are
> > two pins (one is 0, another is 1000), we always enumerate from 0 to
> 1000
> > for just only two pins. This patch enables to start non-zero based
> pin
> > number and to enumerate actually owned pins.
> >
> > For example, there is a system which has huge(500 or 1000) pins. If
> muxing
> > or controlling pins are small, we just define such small pins instead
> of
> > whole pins.
> 
> Seems like you're fixing my code to do what was originally intended :-)
> 
> The maxpin member was something I introduced for sparse ranges
> which would auto-register "dummy pins" for those not included in the
> enumeration.
> 
> That doesn't quite work, so was left behind.
> 
> I'll try applying the patches and see what happens.
> 
> Yours,
> Linus Walleij

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