linux-kernel - Re: [PATCH 0/1] add devm_of_clk_get() and devm_of_clk_get_by

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] [day] [month] [year] [list]

Message-ID: <20151001180357.GG19319@codeaurora.org>
Date:	Thu, 1 Oct 2015 11:03:57 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Paul Osmialowski <pawelo@...g.net.pl>
Cc:	Michael Turquette <mturquette@...libre.com>,
	Russell King <linux@....linux.org.uk>,
	linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/1] add devm_of_clk_get() and devm_of_clk_get_by_name()
 functions

On 10/01, Paul Osmialowski wrote:
> Hi Stephen,
> 
> On Wed, 30 Sep 2015, Stephen Boyd wrote:
> 
> > In the pinctrl node we would have
> > 
> >  	pinctrl {
> >  		compatible = "fsl,kenetis70-pinctrl";
> >  		reg = <0x40049000 0x2000>;
> >  		clocks = <&sim SIM_CLK_SCGC5_PORTA>, <&sim SIM_CLK_SCGC5_PORTB>;
> > 
> > 		uart_default: uart_default {
> > 			mux {
> > 				pins = "porta_3", "portb_2";
> > 				function = "uart";
> > 			};
> > 
> > 			rx {
> > 				bias-pull-pin-default;
> > 			};
> > 		};
> >  	};
> > 
> > And then in the uart node we would have
> > 
> > 	uart@...000 {
> > 		compatible = "vendor,uart";
> > 		reg = <0xf00000 0x100>;
> > 		pinctrl-names = "default";
> > 		pinctrl-0 = <&uart_default>;
> > 	};
> > 
> 
> Seems like there's another thing I wanted to avoid. The correctness of 
> these pin strings will not be checked until the runtime. They need to 
> properly encode pin bank and pin number within the bank. No chances it can 
> be validated at .dtb build time. But I guess this is proper way for 
> generic pinctrl bindings. I mostly (but not completely) based my approach 
> on rockchip examples (e.g. rk3288) but it looks like they are not entirely 
> sane.

I don't see how it could be validated with the <&port pin
function config> binding either. Let's hope that people test
their code, including whatever dts files they produce.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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/