linux-kernel - Re: [PATCH] bus: imx-weim: Take the 'status' property value into account

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]

Date:	Sat, 12 Mar 2016 17:08:49 -0800
From:	Olof Johansson <olof@...om.net>
To:	Shawn Guo <shawnguo@...nel.org>
Cc:	Fabio Estevam <festevam@...il.com>, arm@...nel.org,
	s.hauer@...gutronix.de, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, wolfgang.netbal@...matek.at,
	Fabio Estevam <fabio.estevam@....com>, stable@...r.kernel.org
Subject: Re: [PATCH] bus: imx-weim: Take the 'status' property value into
 account

On Mon, Feb 29, 2016 at 11:36:49AM +0800, Shawn Guo wrote:
> On Mon, Feb 22, 2016 at 09:01:53AM -0300, Fabio Estevam wrote:
> > From: Fabio Estevam <fabio.estevam@....com>
> > 
> > Currently we have an incorrect behaviour when multiple devices
> > are present under the weim node. For example:
> > 
> > &weim {
> > 	...
> > 	status = "okay";
> > 	
> > 	sram@0,0 {
> > 		...
> >         	status = "okay";
> > 	};
> > 
> > 	mram@0,0 {
> > 		...
> >         	status = "disabled";
> >     	};
> > };
> > 
> > In this case only the 'sram' device should be probed and not 'mram'.
> > 
> > However what happens currently is that the status variable is ignored,
> > causing the 'sram' device to be disabled and 'mram' to be enabled.  
> > 
> > Change the weim_parse_dt() function to use
> > for_each_available_child_of_node()so that the devices marked with
> > 'status = disabled' are not probed.
> > 
> > Cc: <stable@...r.kernel.org>
> > Suggested-by: Wolfgang Netbal <wolfgang.netbal@...matek.at>
> > Signed-off-by: Fabio Estevam <fabio.estevam@....com>
> 
> Acked-by: Shawn Guo <shawnguo@...nel.org>
> 
> Arnd, Olof,
> 
> I do not have any other 'driver' patches queued, so please help directly
> apply this one.  Considering this fixes a real problem, it would be good
> if we can merge this through -rc.  But we understand that it's -rc6 now,
> and this doesn't fix a regression or so-critical issue, so it should be
> fine to queue the patch for the next release as well.

Sorry for the high latency here, I had missed this patch and noticed now when
I did a sweep. I've merged it into next/drivers for 4.6.


-Olof