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: <1514367817.30687.59.camel@mtkswgap22>
Date:   Wed, 27 Dec 2017 17:43:37 +0800
From:   Sean Wang <sean.wang@...iatek.com>
To:     Stephen Boyd <sboyd@...eaurora.org>
CC:     <mturquette@...libre.com>, <matthias.bgg@...il.com>,
        <jdelvare@...e.de>, <jamesjj.liao@...iatek.com>,
        <weiyi.lu@...iatek.com>, <kevin-cw.chen@...iatek.com>,
        <shunli.wang@...iatek.com>, <chen.zhong@...iatek.com>,
        <arnd@...db.de>, <linux-mediatek@...ts.infradead.org>,
        <linux-clk@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] clk: mediatek: adjust dependency of reset.c to avoid
 unexpectedly being built

On Tue, 2017-12-26 at 17:19 -0800, Stephen Boyd wrote:
> On 12/26, sean.wang@...iatek.com wrote:
> > From: Sean Wang <sean.wang@...iatek.com>
> > 
> > commit 74cb0d6dde8 ("clk: mediatek: fixup test-building of MediaTek clock
> > drivers") can let the build system looking into the directory where the
> > clock drivers resides and then allow test-building the drivers.
> > 
> > But the change also gives rise to certain incorrect behavior which is
> > reset.c being built even not depending on either COMPILE_TEST or
> > ARCH_MEDIATEK alternative dependency. To get rid of reset.c being built
> > unexpectedly on the other platforms, it would be a good change that the
> > file should be built depending on its own specific configuration rather
> > than just on generic RESET_CONTROLLER one.
> > 
> > Signed-off-by: Sean Wang <sean.wang@...iatek.com>
> > Cc: Jean Delvare <jdelvare@...e.de>
> 
> I've typically seen vendor Kconfigs select the RESET_CONTROLLER
> framework if the vendor Kconfig is enabled. Any reason that same
> method isn't followed here?
> 

I just thought explicit dependency added in Kconfig seems a little good
no matter how the vendor Kconfig forces to select.

But, I believe reset controller is always present on every mediatek SoC,
at least it can be found on infracfg and pericfg subsystem, which is
really fundamental hardware block. So, it's still quite reasonable to
add "RESET_CONTROLLER" to vendor Kconfig.

Once we did it in vendor Kconfig, the Kconfig maybe could become
something like that.

config RESET_MEDIATEK
       bool "MediaTek Reset Driver"
       depends on ARCH_MEDIATEK || (RESET_CONTROLLER && COMPILE_TEST)
       help
         This enables the reset controller driver used on MediaTek SoCs.

where COMPILE_TEST still has to depend on RESET_CONTROLLER to avoid any
compiling error.

I'll make the next version based on above and relevant vendor Kconfig
changes

	Sean



Powered by blists - more mailing lists