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:	Thu, 30 Apr 2015 19:52:12 +0200
From:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
To:	Antoine Tenart <antoine.tenart@...e-electrons.com>,
	Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>
CC:	dwmw2@...radead.org, computersforpeace@...il.com,
	boris.brezillon@...e-electrons.com, zmxu@...vell.com,
	jszhang@...vell.com, linux-arm-kernel@...ts.infradead.org,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Robert Jarzmik <robert.jarzmik@...e.fr>
Subject: Re: [PATCH v4 04/10] mtd: pxa3xx_nand: rework flash detection and
 timing setup

On 30.04.2015 16:31, Antoine Tenart wrote:
> On Thu, Apr 16, 2015 at 01:59:32PM -0300, Ezequiel Garcia wrote:
>> On 04/16/2015 10:41 AM, Sebastian Hesselbarth wrote:
>>
>>> All we need is a function to convert sdr_timings to sane driver
>>> timings. And we really need to split this patch into tiny pieces
>>> otherwise it is not reviewable - or at least I need a full overview
>>> about the driver first.
>>>
>>
>> I think that's a bit of a different issue. This patch seems to be doing
>> two things: it removes the in-driver flash detection *and* reworks
>> timing setup.
>>
>> How about we split this in two or even three patches? Along these lines:
>> 1) introduce timing helpers, 2) rework timing setup, 3) remove in-driver
>> flash detection. Not sure how feasible it is.
>
> That's quite difficult, as you cannot have 1) without having the changes
> made in 2). Flash detection and timing reworks are linked and I'm not
> sure we can have this split into 2 or 3 patches without having a state
> where the driver does not work.

Antoine,

functionally you are right. But splitting the patch into the three
pieces above will heavily reduce the diff-per-patch significantly.
For example, if you introduce 1) without using it, we can only look at
the helper. Then in 2) you actually use that helper and 3) will clean
the mess up.

BTW, I am fine with running the flash on mach-berlin boards with some
default timing for now until we worked out how mtd will deal with
protocol and array timings.

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