Bjorn,
> Let me know if anybody objects. Otherwise, I'll merge it into my
> -next branch tomorrow.
The change is fine with me, thanks to you and Sergei.
Shane
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majo
Grygorii Strashko writes:
> The OMAP I2C driver has a relation to pinctrl-single driver. As result,
> its probe will be deferred during system boot until late init time,
> because the pinctrl-single is initizalized as moudle/device init time.
> This, in turn, will delay initialization of all I2C
On Mon, Jun 3, 2013 at 4:04 AM, Sergei Shtylyov
wrote:
> Hello.
>
>
> On 03-06-2013 14:24, Shane Huang wrote:
>
>> To add AMD CZ SATA controller device ID of IDE mode.
>
>
>> Signed-off-by: Shane Huang
>> Reviewed-by: Tejun Heo
>> Cc: sta...@vger.kernel.org
>> ---
>> drivers/ata/ahci.c |
Hello.
On 03-06-2013 14:24, Shane Huang wrote:
To add AMD CZ SMBus controller device ID.
Signed-off-by: Shane Huang
Reviewed-by: Tejun Heo
Reviewed-by: Jean Delvare
Cc: sta...@vger.kernel.org
[...]
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 22449c1..b10a5b4 10
Hello.
On 03-06-2013 14:24, Shane Huang wrote:
To add AMD CZ SATA controller device ID of IDE mode.
Signed-off-by: Shane Huang
Reviewed-by: Tejun Heo
Cc: sta...@vger.kernel.org
---
drivers/ata/ahci.c | 1 +
drivers/pci/quirks.c| 2 ++
include/linux/pci_ids.h | 1 +
3 files ch
Moorestown support is removed from kernel and Medfield is supported by
i2c-designware-pci. But i2c-intel-mid is still in upstream and community
resources are wasted to maintain it.
Signed-off-by: Andy Shevchenko
---
drivers/i2c/busses/Kconfig | 10 -
drivers/i2c/busses/Makefile
Hi, Wolfram.
I remember I send once patch to remove obsolete driver i2c-intel-mid,
but it's still in upstream and community resources are spent to maintain
it. Moorestown support is removed from kernel year ago (?), and Medfield
is supported by i2c-designware-pci.
I'm just wondering what's the pl
We've been lucky not to have any interrupts fire during the suspend
path, otherwise we would have unpredictable behaviour in the kernel.
Based on the logic of the kernel code interrupts from i2c should be
prohibited during suspend. Kernel writes 0 to the I2C_IE register in
the omap_i2c_runtime_sus