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]
Message-ID: <20130211212105.GX4801@atomide.com>
Date:	Mon, 11 Feb 2013 13:21:05 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Linus Walleij <linus.walleij@...ricsson.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Stephen Warren <swarren@...dia.com>,
	Anmar Oueja <anmar.oueja@...aro.org>,
	Laurent Meunier <laurent.meunier@...com>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH] pinctrl/pinconfig: add debug interface

* Stephen Warren <swarren@...dotorg.org> [130211 13:17]:
> On 02/11/2013 02:00 PM, Tony Lindgren wrote:
> > * Stephen Warren <swarren@...dotorg.org> [130211 12:57]:
> >> On 02/10/2013 01:11 PM, Linus Walleij wrote:
> >>> From: Laurent Meunier <laurent.meunier@...com>
> >>>
> >>> This update adds a debugfs interface to modify a pin configuration
> >>> for a given state in the pinctrl map. This allows to modify the
> >>> configuration for a non-active state, typically sleep state.
> >>> This configuration is not applied right away, but only when the state
> >>> will be entered.
> >>>
> >>> This solution is mandated for us by HW validation: in order
> >>> to test and verify several pin configurations during sleep without
> >>> recompiling the software.
> >>
> >> I never understood why HW engineers can't just recompile the kernel.
> >> Besides, it's just a device tree change these days - no recompile even
> >> required, right?
> > 
> > Typically when bringing up a new board you do not have the driver
> > specific mux settings verified. For developers, it's easiest to tweak
> > the muxing during runtime do the drivers as a loadable module, then
> > export the verified mux configuration into a .dts file.
> 
> Well HW engineers typically just write to the HW registers directly
> rather than screwing around with the Linux pinctrl tables and
> unloading/reloading drivers.

I've seen cases where most of the mux register configuration are
done correctly by HW engineers.. But there's always been some pieces
of the pin configuration wrong initially and that needs to be fixed by
the driver people to get things working.

Being able to set the mux configuration via debugfs is also very
useful for the case of adding external devices to your proto boards
like beagle etc.

Regards,

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