[PATCH 09/11] drivers/scsi: include <module.h> for modular ufshcd-pltfrm code

[PATCH 09/11] drivers/scsi: include <module.h> for modular ufshcd-pltfrm code

[Paul Gortmaker]

This file is built off of a tristate Kconfig option and also contains
modular function calls so it should explicitly include module.h to
avoid compile breakage during header shuffles done in the future.

Cc: Vinayak Holikatti <vinholikatti@gmail.com>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 drivers/scsi/ufs/ufshcd-pltfrm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index 7db9564f507d..1c0bac8a7e4a 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -33,6 +33,7 @@
  * this program.
  */
 
+#include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/of.h>
-- 
2.2.1

Re: [PATCH 09/11] drivers/scsi: include <module.h> for modular ufshcd-pltfrm code

[James Bottomley]

On Thu, 2015-04-30 at 21:47 -0400, Paul Gortmaker wrote:
> This file is built off of a tristate Kconfig option and also contains
> modular function calls so it should explicitly include module.h to
> avoid compile breakage during header shuffles done in the future.

I don't understand your logic.  The ufs code made a design choice to
consolidate most headers for the hcd code in a local include (ufshcd.h),
which includes module.h, so why would they explicitly need it here as
well?  And if we follow your logic, why wouldn't they also need to
duplicate everything else (like the scsi includes)?

James

Re: [PATCH 09/11] drivers/scsi: include <module.h> for modular ufshcd-pltfrm code

[Paul Gortmaker]

On 15-04-30 10:35 PM, James Bottomley wrote:
> On Thu, 2015-04-30 at 21:47 -0400, Paul Gortmaker wrote:
>> This file is built off of a tristate Kconfig option and also contains
>> modular function calls so it should explicitly include module.h to
>> avoid compile breakage during header shuffles done in the future.
> 
> I don't understand your logic.  The ufs code made a design choice to
> consolidate most headers for the hcd code in a local include (ufshcd.h),
> which includes module.h, so why would they explicitly need it here as
> well?  And if we follow your logic, why wouldn't they also need to
> duplicate everything else (like the scsi includes)?

In my original build testing this file failed to compile once the
modular code was moved from init.h to module.h as per the description
in the 0/11.

Perhaps since that testing something else has changed.  I will drop this
patch and retest and if it no longer fails, then great.

Paul.
--

> 
> James
> 
> 

Re: [PATCH 09/11] drivers/scsi: include <module.h> for modular ufshcd-pltfrm code

[James Bottomley]

On Fri, 2015-05-01 at 09:37 -0400, Paul Gortmaker wrote:
> On 15-04-30 10:35 PM, James Bottomley wrote:
> > On Thu, 2015-04-30 at 21:47 -0400, Paul Gortmaker wrote:
> >> This file is built off of a tristate Kconfig option and also contains
> >> modular function calls so it should explicitly include module.h to
> >> avoid compile breakage during header shuffles done in the future.
> > 
> > I don't understand your logic.  The ufs code made a design choice to
> > consolidate most headers for the hcd code in a local include (ufshcd.h),
> > which includes module.h, so why would they explicitly need it here as
> > well?  And if we follow your logic, why wouldn't they also need to
> > duplicate everything else (like the scsi includes)?
> 
> In my original build testing this file failed to compile once the
> modular code was moved from init.h to module.h as per the description
> in the 0/11.

Just as a point of principle, you didn't send the 0/11 patch, so I only
have this one to go by.

> Perhaps since that testing something else has changed.  I will drop this
> patch and retest and if it no longer fails, then great.

Sounds good.

James