From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753223AbbG1PTn (ORCPT ); Tue, 28 Jul 2015 11:19:43 -0400 Received: from down.free-electrons.com ([37.187.137.238]:38419 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751715AbbG1PTm (ORCPT ); Tue, 28 Jul 2015 11:19:42 -0400 Date: Tue, 28 Jul 2015 17:19:40 +0200 From: Boris Brezillon To: Hans de Goede Cc: Michal Suchanek , David Woodhouse , Brian Norris , Petros Angelatos , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2] New NAND chip IDs Message-ID: <20150728171940.481e8581@bbrezillon> In-Reply-To: <55B79696.40906@redhat.com> References: <55B79696.40906@redhat.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hans, Here is a more appropriate answer ;-) On Tue, 28 Jul 2015 16:49:58 +0200 Hans de Goede 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