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: <20150728171940.481e8581@bbrezillon>
Date:	Tue, 28 Jul 2015 17:19:40 +0200
From:	Boris Brezillon <boris.brezillon@...e-electrons.com>
To:	Hans de Goede <hdegoede@...hat.com>
Cc:	Michal Suchanek <hramrach@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Brian Norris <computersforpeace@...il.com>,
	Petros Angelatos <petrosagg@...il.com>,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] New NAND chip IDs

Hi Hans,

Here is a more appropriate answer ;-)

On Tue, 28 Jul 2015 16:49:58 +0200
Hans de Goede <hdegoede@...hat.com> wrote:

> Hi,
> 
> On 07/28/2015 04:29 PM, Michal Suchanek wrote:
> > Hello,
> >
> > the NAND chips on Cubietech boards are not known to Linux.
> >
> > I used Petros Angelatos' patch from sunxi experimental tree for one chip and
> > added another chip.
> >
> > I hope it's ok to send both patches to avoid merge conflict.
> 
> I do not think that these patches are a good idea, this will lead to an
> ever growing manual maintained list of ids, and that is not maintainable
> IMHO.
> 
> For Samsung chips we only need the ecc strength and size the rest is already
> detected on the fly, and I've a patch in my personal tree to get the
> ecc strengt and size from the nand without needing to have an entry per
> chip:
> 
> https://github.com/jwrdegoede/linux-sunxi/commit/53b335d33232753b7aa70298009158baadf5a6bf
> 
> This is IMHO a much better solution.

Yes, indeed, this is a better approach, but AFAIR, not all Samsung
chips use this layout to expose the ECC strength/size info, and I
guess this is why this method is not used to retrieve the ECC
requirements.

But I think we could avoid this full ids list by putting some
detection code into vendor specific files, this way we could handle
chips by families instead of describing all of them.

Best Regards,

Boris
-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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