Re: [PATCH 2/2] i2c: designware: Add support for AMD I2C controller

[Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

On Mon, Sep 22, 2014 at 12:12:07PM +0300, Mika Westerberg wrote:
> On Sat, Sep 20, 2014 at 11:36:34AM +0200, Wolfram Sang wrote:
> > On Thu, Sep 18, 2014 at 12:26:07PM +0300, Mika Westerberg wrote:
> > > From: Carl Peng <carlpeng008-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > 
> > > Add support for AMD version of the DW I2C host controller. The device is
> > > enumerated from ACPI namespace with ACPI ID AMD0010. Because the core
> > > driver needs an input source clock, and this is not an Intel LPSS device
> > > where clocks are provided through drivers/acpi/acpi_lpss.c, we register the
> > > clock ourselves if the clock rate is given in ->driver_data.
> > > 
> > > Signed-off-by: Carl Peng <carlpeng008-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > Signed-off-by: Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > > ---
> > 
> > Applied to for-next, still wondering...
> 
> Thanks!

I reconsidered and these two patches are not in i2c/for-next because of
two reasons:

1) They do not apply cleanly on top of other i2c-designware changes I
applied (check i2c/for-next I just pushed out). The conflicts might not
be hard, but they were not trivial enough for me to do them inbetween
other things. I'd be very happy about a repost on top of i2c/for-next.

> 
> > 
> > >  drivers/i2c/busses/Kconfig                  |  1 +
> > >  drivers/i2c/busses/i2c-designware-platdrv.c | 27 +++++++++++++++++++++++++++
> > >  2 files changed, 28 insertions(+)
> > > 
> > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > > index 2ac87fa3058d..9384498ef3c1 100644
> > > --- a/drivers/i2c/busses/Kconfig
> > > +++ b/drivers/i2c/busses/Kconfig
> > > @@ -422,6 +422,7 @@ config I2C_DESIGNWARE_CORE
> > >  
> > >  config I2C_DESIGNWARE_PLATFORM
> > >  	tristate "Synopsys DesignWare Platform"
> > > +	depends on COMMON_CLK
> > 
> > ... do all previous users have COMMON_CLK?
> 
> The driver is being used on x86, ARM and ARC it seems. For x86 and ARM
> we pretty much have COMMON_CLK nowadays but I'm not sure about ARC.

2) "pretty much have" is not so convincing to me. That is such a generic
core, it probably has enough out-of-tree users as well. And with all
these ACPI regressions from this cycle, I am very cautious right now.
Brainstorming: What about "depends on (ACPI && COMMON_CLK) || !ACPI"?


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]