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: <561D40C4.4030703@gmail.com>
Date:	Tue, 13 Oct 2015 10:35:00 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Josh Cartwright <joshc@....teric.us>,
	Anup Patel <anup.patel@...adcom.com>
CC:	Florian Fainelli <f.fainelli@...il.com>,
	Scott Branden <sbranden@...adcom.com>,
	Brian Norris <computersforpeace@...il.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	David Woodhouse <dwmw2@...radead.org>,
	Ray Jui <rjui@...adcom.com>,
	Pramod Kumar <pramodku@...adcom.com>,
	Vikram Prakash <vikramp@...adcom.com>,
	Sandeep Tripathy <tripathy@...adcom.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
	Rafal Milecki <zajec5@...il.com>
Subject: Re: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND
 controller

On 12/10/15 14:54, Josh Cartwright wrote:
> On Wed, Oct 07, 2015 at 03:33:50AM +0000, Anup Patel wrote:
>> From: Florian Fainelli [mailto:f.fainelli@...il.com]
>>> On 06/10/15 15:25, Scott Branden wrote:
> [..]
>>> Then instead of adding a "reset flag" to Device Tree, another approach could be
>>> to put the desired or currently configured exhaustive list of NAND timings in
>>> Device Tree, and based on that you could have this:
>>>
>>> - the NAND controller driver finds that these timings match the current
>>> configuration, you are good to go
>>>
>>> - the NAND controller drivers finds a difference in how current timings are
>>> configured vs. desired timings, and issues a controller reset, prior to applying
>>> new timing configuration
>>
>> To add to this ...
>>
>> The mechanism to reset is BRCM NAND controller is SOC specific so the
>> SoC independent BRCM NAND driver (i.e. brcmnand.c) does not know how
>> to reset the NAND controller.
>>
>> For iProc SoC family, the NAND controller reset is through IDM register
>> space which is only iomap'ed by iproc_nand.c.
>>
>> We might end-up having one more SoC specific callback which will be
>> Provided by iproc_nand.c to brcmnand.c.
> 
> Not that I'm familiar with these SoCs, but I did want to chime in and
> make sure you are aware of the existing reset_controller_dev
> abstraction, which is intended to solve exactly this problem.  Including
> a reset_control_get_optional() that might fit your use case.  See
> include/linux/reset{,-controller}.h.

I almost suggested that, and then looked more closely at where this
reset register is located, and it happens to be in the NAND controller
itself (IPROC IDM which is the iProc SHIM to the NAND controller), so
coming up with a reset controller driver and a reset controller consumer
for that simple use case sounds both unnecessary and complex.

The core of the discussion is about disguising this NAND controller
reset as a way to preserve previously configured NAND timings, which is
at best a hack and an unstated dependency with the firmware.
-- 
Florian
--
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