linux-kernel - Re: linux-next: build failure after merge of the mfd tree

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: <20120522224214.GG10210@sortiz-mobl>
Date:	Wed, 23 May 2012 00:42:14 +0200
From:	Samuel Ortiz <sameo@...ux.intel.com>
To:	Lee Jones <lee.jones@...aro.org>,
	Linus Walleij <linus.walleij@...aro.org>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: build failure after merge of the mfd tree

Hi Lee,

On Mon, May 21, 2012 at 11:28:23AM +0100, Lee Jones wrote:
> When CONFIG_AB8500_CORE is set, building ab8500-core.c and
> !(CONFIG_UX500_SOC_DB8500 | CONFIG_MFD_DB8500_PRCMU), both
> db8500-prcmu.h and dbx500-prcmu.h take it upon themselves to _both_
> create 'return 0' inline functions for the following:
> 
> prcmu_abb_read()
> prcmu_abb_write()
> prcmu_config_clkout()
> prcmu_ac_wake_req()
> prcmu_ac_sleep_req()
> 
> I think we need a Kconfig rule to prevent this from happening, but
> I'm not sure what the correct logic would be. 
Do you want the above routines to be NOOPs when !CONFIG_MFD_DB8500_PRCMU or
when !CONFIG_UX500_SOC_DB8500 ? It would make more sense to define them as
NOOP when !CONFIG_MFD_DB8500_PRCMU and remove all those definitions from
dbx500-prmcu.h
But I may be missing some of your architecture dependencies.

Something like that:

diff --git a/include/linux/mfd/dbx500-prcmu.h b/include/linux/mfd/dbx500-prcmu.h
index d7674eb..8515547 100644
--- a/include/linux/mfd/dbx500-prcmu.h
+++ b/include/linux/mfd/dbx500-prcmu.h
@@ -366,12 +366,8 @@ static inline void prcmu_get_abb_event_buffer(void __iomem **buf)
 		db8500_prcmu_get_abb_event_buffer(buf);
 }
 
-int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size);
-int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size);
 int prcmu_abb_write_masked(u8 slave, u8 reg, u8 *value, u8 *mask, u8 size);
 
-int prcmu_config_clkout(u8 clkout, u8 source, u8 div);
-
 static inline int prcmu_request_clock(u8 clock, bool enable)
 {
 	if (cpu_is_u5500())
@@ -447,8 +443,6 @@ static inline u16 prcmu_get_reset_code(void)
 		return db8500_prcmu_get_reset_code();
 }
 
-void prcmu_ac_wake_req(void);
-void prcmu_ac_sleep_req(void);
 static inline void prcmu_modem_reset(void)
 {
 	if (cpu_is_u5500())
@@ -611,27 +605,12 @@ static inline void prcmu_enable_wakeups(u32 wakeups) {}
 
 static inline void prcmu_disable_wakeups(void) {}
 
-static inline int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size)
-{
-	return -ENOSYS;
-}
-
-static inline int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size)
-{
-	return -ENOSYS;
-}
-
 static inline int prcmu_abb_write_masked(u8 slave, u8 reg, u8 *value, u8 *mask,
 	u8 size)
 {
 	return -ENOSYS;
 }
 
-static inline int prcmu_config_clkout(u8 clkout, u8 source, u8 div)
-{
-	return 0;
-}
-
 static inline int prcmu_request_clock(u8 clock, bool enable)
 {
 	return 0;
@@ -689,10 +668,6 @@ static inline u16 prcmu_get_reset_code(void)
 	return 0;
 }
 
-static inline void prcmu_ac_wake_req(void) {}
-
-static inline void prcmu_ac_sleep_req(void) {}
-
 static inline void prcmu_modem_reset(void) {}
 
 static inline bool prcmu_is_ac_wake_requested(void)

I would appreciate if we could have a fix for this one sooner than later as
I'm planning to send my pull request by the end of this week.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.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/