linux-kernel - Re: [PATCH v3 01/11] MFD: DA9052 MFD core module

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]

Message-ID: <20110809145252.GC15861@opensource.wolfsonmicro.com>
Date:	Tue, 9 Aug 2011 23:52:53 +0900
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Ashish Jangam <Ashish.Jangam@...tcummins.com>
Cc:	"sameo@...nedhand.com" <sameo@...nedhand.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dajun <dajun.chen@...semi.com>,
	"linaro-dev@...ts.linaro.org" <linaro-dev@...ts.linaro.org>
Subject: Re: [PATCH v3 01/11] MFD: DA9052 MFD core module

On Tue, Aug 09, 2011 at 08:45:47AM +0000, Ashish Jangam wrote:

> > Could do with blank lines between blocks.  Though looking at the code
> > here I don't understand why these are compile options at all, or if they
> > need to be compile options for some reason why they're not independantly
> > selectable?

> DA9052 PMIC chip id may get OTP therefore chip id cannot be used as 
> a distinguishing factor. Hence these compile time options were introduced.
> DA9053 is a higher version of DA9052 therefore not independently selectable.
> This means that there can be either DA9052 or DA9053 on system. I need to correct
> this Kconfig to take care of this. 

No, this is not acceptable in the kernel.  One kernel can support many
different boards so you need to be able to compile support for all chips
in simultaneously.  If you can't identify based on the hardware you need
to rely on the device being registered correctly by the user.

> > This should be runtime detected based on the device name, either from
> > the device registration or by reading back chip identification.

> As said above getting chip info will not work in DA9053/53 case. Also DA9052 code 
> works for DA9053 except for few minor changes in MFD and regulator module.
> In this case registering different device will also require a preprocessor directive
> Or separate DA9053 file therefore this option was not opt. 

No, this is not acceptable.  One kernel build should be able to support
many different boards.  Like I said in my quote above you need to either
use the device registration or chip registers - if chip registers are
not suitable I guess that means you need to use the device registration.
There are a large number of examples of this in the kernel.

I know the Linaro guys have offered to help you out with this stuff, can
you please work with them?  You are obviously experiencing a lot of
difficulties with understanding the requirements and standards for
getting your code into the standard kernel, they really know what
they're doing.
--
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/