Re: [PATCH] i2c/designware: dw_i2c_init_driver as subsys initcall

2012-02-26 Thread Viresh Kumar 
On 11/16/2011 10:28 AM, Pratyush ANAND wrote:
 There are few drivers(for example stmpe-gpio) which are available on i2c
 bus but has been initialized as subsys initcall. Therefore i2c driver
 must also be initialized as subsys initcall.
 
 Signed-off-by: Pratyush Anand pratyush.an...@st.com
 ---
  drivers/i2c/busses/i2c-designware-pcidrv.c  |2 +-
  drivers/i2c/busses/i2c-designware-platdrv.c |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c 
 b/drivers/i2c/busses/i2c-designware-pcidrv.c
 index 9e89e73..7854565 100644
 --- a/drivers/i2c/busses/i2c-designware-pcidrv.c
 +++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
 @@ -379,7 +379,7 @@ static int __init dw_i2c_init_driver(void)
  {
   return  pci_register_driver(dw_i2c_driver);
  }
 -module_init(dw_i2c_init_driver);
 +subsys_initcall(dw_i2c_init_driver);
  
  static void __exit dw_i2c_exit_driver(void)
  {
 diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
 b/drivers/i2c/busses/i2c-designware-platdrv.c
 index 2d3657a..4fbdcd5 100644
 --- a/drivers/i2c/busses/i2c-designware-platdrv.c
 +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
 @@ -202,7 +202,7 @@ static int __init dw_i2c_init_driver(void)
  {
   return platform_driver_probe(dw_i2c_driver, dw_i2c_probe);
  }
 -module_init(dw_i2c_init_driver);
 +subsys_initcall(dw_i2c_init_driver);
  
  static void __exit dw_i2c_exit_driver(void)
  {

Hi Jean/Ben/Wolfram,

Can anyone of you apply this patch, if it looks fine.

-- 
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] i2c/designware: dw_i2c_init_driver as subsys initcall

2012-02-24 Thread Viresh Kumar 
On 11/16/2011 1:52 PM, Baruch Siach wrote:
 Dependencies should be stated explicitly. Since this subsys_initcall thing is 
 quite common among the i2c masters I'm willing to ack this one for now. But 
 the real solution is to make the dependencies between devices clear and 
 explicit.

Baruch,

Did you apply this patch?

-- 
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] i2c/designware: dw_i2c_init_driver as subsys initcall

2012-02-24 Thread Baruch Siach 
Hi Viresh,

On Fri, Feb 24, 2012 at 04:32:08PM +0530, Viresh Kumar wrote:
 On 11/16/2011 1:52 PM, Baruch Siach wrote:
  Dependencies should be stated explicitly. Since this subsys_initcall thing 
  is 
  quite common among the i2c masters I'm willing to ack this one for now. But 
  the real solution is to make the dependencies between devices clear and 
  explicit.
 
 Baruch,
 
 Did you apply this patch?

Nope. If you want it applied please end to the I2C subsystem maintainers.

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] i2c/designware: dw_i2c_init_driver as subsys initcall

2011-11-16 Thread Baruch Siach 
Hi Shiraz,

On Wed, Nov 16, 2011 at 10:57:19AM +0530, Shiraz Hashim wrote:
 On Wed, Nov 16, 2011 at 01:14:41PM +0800, Baruch Siach wrote:
  Hi Pratyush Anand,
  
  On Wed, Nov 16, 2011 at 10:28:07AM +0530, Pratyush Anand wrote:
   There are few drivers(for example stmpe-gpio) which are available on i2c
   bus but has been initialized as subsys initcall. Therefore i2c driver
   must also be initialized as subsys initcall.
   
   Signed-off-by: Pratyush Anand pratyush.an...@st.com
   ---
  
  NAK.
  
  Dependency problem like this one should be solved using the probe deferral 
  mechanism, when it's merged 
  (http://thread.gmane.org/gmane.linux.ports.arm.omap/65436). Sprinkling 
  those 
  really_really_early_initcall() all over the place is unreasonable IMO.
 
 Being a bus driver in this particular case, don't you think that it
 should explicitly appear before devices using this bus.

Dependencies should be stated explicitly. Since this subsys_initcall thing is 
quite common among the i2c masters I'm willing to ack this one for now. But 
the real solution is to make the dependencies between devices clear and 
explicit.

baruch

-- 
 ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] i2c/designware: dw_i2c_init_driver as subsys initcall

2011-11-15 Thread Baruch Siach 
Hi Pratyush Anand,

On Wed, Nov 16, 2011 at 10:28:07AM +0530, Pratyush Anand wrote:
 There are few drivers(for example stmpe-gpio) which are available on i2c
 bus but has been initialized as subsys initcall. Therefore i2c driver
 must also be initialized as subsys initcall.
 
 Signed-off-by: Pratyush Anand pratyush.an...@st.com
 ---

NAK.

Dependency problem like this one should be solved using the probe deferral 
mechanism, when it's merged 
(http://thread.gmane.org/gmane.linux.ports.arm.omap/65436). Sprinkling those 
really_really_early_initcall() all over the place is unreasonable IMO.

baruch

  drivers/i2c/busses/i2c-designware-pcidrv.c  |2 +-
  drivers/i2c/busses/i2c-designware-platdrv.c |2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c 
 b/drivers/i2c/busses/i2c-designware-pcidrv.c
 index 9e89e73..7854565 100644
 --- a/drivers/i2c/busses/i2c-designware-pcidrv.c
 +++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
 @@ -379,7 +379,7 @@ static int __init dw_i2c_init_driver(void)
  {
   return  pci_register_driver(dw_i2c_driver);
  }
 -module_init(dw_i2c_init_driver);
 +subsys_initcall(dw_i2c_init_driver);
  
  static void __exit dw_i2c_exit_driver(void)
  {
 diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
 b/drivers/i2c/busses/i2c-designware-platdrv.c
 index 2d3657a..4fbdcd5 100644
 --- a/drivers/i2c/busses/i2c-designware-platdrv.c
 +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
 @@ -202,7 +202,7 @@ static int __init dw_i2c_init_driver(void)
  {
   return platform_driver_probe(dw_i2c_driver, dw_i2c_probe);
  }
 -module_init(dw_i2c_init_driver);
 +subsys_initcall(dw_i2c_init_driver);
  
  static void __exit dw_i2c_exit_driver(void)
  {

-- 
 ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] i2c/designware: dw_i2c_init_driver as subsys initcall

2011-11-15 Thread Shiraz Hashim 
Hi Baruch,

On Wed, Nov 16, 2011 at 01:14:41PM +0800, Baruch Siach wrote:
 Hi Pratyush Anand,
 
 On Wed, Nov 16, 2011 at 10:28:07AM +0530, Pratyush Anand wrote:
  There are few drivers(for example stmpe-gpio) which are available on i2c
  bus but has been initialized as subsys initcall. Therefore i2c driver
  must also be initialized as subsys initcall.
  
  Signed-off-by: Pratyush Anand pratyush.an...@st.com
  ---
 
 NAK.
 
 Dependency problem like this one should be solved using the probe deferral 
 mechanism, when it's merged 
 (http://thread.gmane.org/gmane.linux.ports.arm.omap/65436). Sprinkling those 
 really_really_early_initcall() all over the place is unreasonable IMO.

Being a bus driver in this particular case, don't you think that it
should explicitly appear before devices using this bus.

--
regards
Shiraz
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html