[PATCH 1/2] i2c: designware: register clkdev during acpi device configuration

[Ken Xue]

DW I2C driver tries to register a clk from id->driver_data as an
alternative way besides intel lpss. But code doesn't register the
clk to clkdev. So, devm_clk_get will fail during probe.

The patch can fix this issue.

Signed-off-by: Ken Xue 
Signed-off-by: Xiangliang Yu 
Cc: sta...@vger.kernel.org
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 3dd2de3..9ee1fc6 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -78,6 +79,7 @@ static int dw_i2c_acpi_configure(struct platform_device *pdev)
 {
struct dw_i2c_dev *dev = platform_get_drvdata(pdev);
const struct acpi_device_id *id;
+   struct clk *clk;
 
dev->adapter.nr = -1;
dev->tx_fifo_depth = 32;
@@ -97,9 +99,11 @@ static int dw_i2c_acpi_configure(struct platform_device 
*pdev)
 * id->driver_data.
 */
id = acpi_match_device(pdev->dev.driver->acpi_match_table, >dev);
-   if (id && id->driver_data)
-   clk_register_fixed_rate(>dev, dev_name(>dev), NULL,
-   CLK_IS_ROOT, id->driver_data);
+   if (id && id->driver_data) {
+   clk = clk_register_fixed_rate(>dev, dev_name(>dev),
+   NULL, CLK_IS_ROOT, id->driver_data);
+   clk_register_clkdev(clk, NULL, dev_name(>dev));
+   }
 
return 0;
 }
-- 
1.9.1



--
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

[PATCH 2/2] i2c: designware: remove freq definition for "AMD0010" in acpi_device_id

[Ken Xue]

Now, AMD ACPI devices can be reworked by APD which is similar to intel
lpss. And the clkdev for "AMD0010" can be registered in APD. So, try
to remove freq definition from id->driver_data for "AMD0010".

Make "AMD0010" look like other ones.

Signed-off-by: Ken Xue 
Signed-off-by: Xiangliang Yu 
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 9ee1fc6..c8acbff 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -125,7 +125,7 @@ static const struct acpi_device_id dw_i2c_acpi_match[] = {
{ "INT3433", 0 },
{ "80860F41", 0 },
{ "808622C1", 0 },
-   { "AMD0010", 133 * 1000 * 1000 },
+   { "AMD0010", 0 },
{ }
 };
 MODULE_DEVICE_TABLE(acpi, dw_i2c_acpi_match);
-- 
1.9.1



--
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

[RESEND PATCH 5/9] eeprom: at24: export the serial number through sysfs

[Bartosz Golaszewski]

The at24 driver is now capable of reading the serial number from at24cs
EEPROM chips. Export the serial number through sysfs.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/misc/eeprom/at24.c | 44 
 1 file changed, 40 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 4d4a793..0eded22 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -64,6 +64,7 @@ struct at24_data {
 */
struct mutex lock;
struct bin_attribute bin;
+   struct bin_attribute *bin_serial;
 
u8 *writebuf;
unsigned write_max;
@@ -102,6 +103,7 @@ MODULE_PARM_DESC(write_timeout, "Time (in ms) to try writes 
(default 25)");
 
 #define AT24_BITMASK(x) (BIT(x) - 1)
 
+#define AT24CS_SERIAL_SIZE 16
 #define AT24CS_SERIAL_ADDR(addr) (addr + 0x08)
 
 /* create non-zero magic value for given eeprom parameters */
@@ -156,10 +158,8 @@ static struct i2c_client *at24_translate_offset(struct 
at24_data *at24,
return at24->client[i];
 }
 
-static int __attribute__((unused)) at24cs_eeprom_serial_read(
-   struct at24_data *at24,
-   char *buf, unsigned offset,
-   size_t count)
+static int at24cs_eeprom_serial_read(struct at24_data *at24, char *buf,
+unsigned offset, size_t count)
 {
unsigned long timeout, read_time;
struct i2c_client *client;
@@ -221,6 +221,16 @@ static int __attribute__((unused)) 
at24cs_eeprom_serial_read(
return -ETIMEDOUT;
 }
 
+static ssize_t at24cs_bin_serial_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t off, size_t count)
+{
+   struct at24_data *at24;
+
+   at24 = dev_get_drvdata(container_of(kobj, struct device, kobj));
+   return at24cs_eeprom_serial_read(at24, buf, off, count);
+}
+
 static ssize_t at24_eeprom_read(struct at24_data *at24, char *buf,
unsigned offset, size_t count)
 {
@@ -637,6 +647,30 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
at24->bin.read = at24_bin_read;
at24->bin.size = chip.byte_len;
 
+   if (at24->chip.flags & AT24_FLAG_SERIAL) {
+   /*
+* For EEPROMs containing the serial number export an
+* additional file allowing allowing convenvient access
+* to it from user-space.
+*/
+   at24->bin_serial = devm_kzalloc(>dev,
+   sizeof(struct bin_attribute),
+   GFP_KERNEL);
+   if (!at24->bin_serial)
+   return -ENOMEM;
+
+   sysfs_bin_attr_init(at24->bin_serial);
+   at24->bin_serial->attr.name = "serial";
+   at24->bin_serial->attr.mode = S_IRUSR;
+   at24->bin_serial->read = at24cs_bin_serial_read;
+   at24->bin_serial->size = AT24CS_SERIAL_SIZE;
+
+   err = sysfs_create_bin_file(>dev.kobj,
+   at24->bin_serial);
+   if (err)
+   goto err_clients;
+   }
+
at24->macc.read = at24_macc_read;
 
writable = !(chip.flags & AT24_FLAG_READONLY);
@@ -736,6 +770,8 @@ static int at24_remove(struct i2c_client *client)
 
at24 = i2c_get_clientdata(client);
sysfs_remove_bin_file(>dev.kobj, >bin);
+   if (at24->bin_serial)
+   sysfs_remove_bin_file(>dev.kobj, at24->bin_serial);
 
for (i = 1; i < at24->num_addresses; i++)
i2c_unregister_device(at24->client[i]);
-- 
2.1.4

--
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

[RESEND PATCH 6/9] eeprom: at24: improve the device_id table readability

[Bartosz Golaszewski]

Improve the readability of the device table by separating columns with
tabs.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/misc/eeprom/at24.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 0eded22..0d34b94 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -113,23 +113,23 @@ MODULE_PARM_DESC(write_timeout, "Time (in ms) to try 
writes (default 25)");
 
 static const struct i2c_device_id at24_ids[] = {
/* needs 8 addresses as A0-A2 are ignored */
-   { "24c00", AT24_DEVICE_MAGIC(128 / 8, AT24_FLAG_TAKE8ADDR) },
+   { "24c00",  AT24_DEVICE_MAGIC(128 / 8,  AT24_FLAG_TAKE8ADDR) },
/* old variants can't be handled with this generic entry! */
-   { "24c01", AT24_DEVICE_MAGIC(1024 / 8, 0) },
-   { "24c02", AT24_DEVICE_MAGIC(2048 / 8, 0) },
+   { "24c01",  AT24_DEVICE_MAGIC(1024 / 8, 0) },
+   { "24c02",  AT24_DEVICE_MAGIC(2048 / 8, 0) },
/* spd is a 24c02 in memory DIMMs */
-   { "spd", AT24_DEVICE_MAGIC(2048 / 8,
-   AT24_FLAG_READONLY | AT24_FLAG_IRUGO) },
-   { "24c04", AT24_DEVICE_MAGIC(4096 / 8, 0) },
+   { "spd",AT24_DEVICE_MAGIC(2048 / 8,
+   AT24_FLAG_READONLY | AT24_FLAG_IRUGO) },
+   { "24c04",  AT24_DEVICE_MAGIC(4096 / 8, 0) },
/* 24rf08 quirk is handled at i2c-core */
-   { "24c08", AT24_DEVICE_MAGIC(8192 / 8, 0) },
-   { "24c16", AT24_DEVICE_MAGIC(16384 / 8, 0) },
-   { "24c32", AT24_DEVICE_MAGIC(32768 / 8, AT24_FLAG_ADDR16) },
-   { "24c64", AT24_DEVICE_MAGIC(65536 / 8, AT24_FLAG_ADDR16) },
-   { "24c128", AT24_DEVICE_MAGIC(131072 / 8, AT24_FLAG_ADDR16) },
-   { "24c256", AT24_DEVICE_MAGIC(262144 / 8, AT24_FLAG_ADDR16) },
-   { "24c512", AT24_DEVICE_MAGIC(524288 / 8, AT24_FLAG_ADDR16) },
-   { "24c1024", AT24_DEVICE_MAGIC(1048576 / 8, AT24_FLAG_ADDR16) },
+   { "24c08",  AT24_DEVICE_MAGIC(8192 / 8, 0) },
+   { "24c16",  AT24_DEVICE_MAGIC(16384 / 8,0) },
+   { "24c32",  AT24_DEVICE_MAGIC(32768 / 8,AT24_FLAG_ADDR16) },
+   { "24c64",  AT24_DEVICE_MAGIC(65536 / 8,AT24_FLAG_ADDR16) },
+   { "24c128", AT24_DEVICE_MAGIC(131072 / 8,   AT24_FLAG_ADDR16) },
+   { "24c256", AT24_DEVICE_MAGIC(262144 / 8,   AT24_FLAG_ADDR16) },
+   { "24c512", AT24_DEVICE_MAGIC(524288 / 8,   AT24_FLAG_ADDR16) },
+   { "24c1024",AT24_DEVICE_MAGIC(1048576 / 8,  AT24_FLAG_ADDR16) },
{ "at24", 0 },
{ /* END OF LIST */ }
 };
-- 
2.1.4

--
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

[RESEND PATCH 9/9] eeprom: at24: readability tweaks

[Bartosz Golaszewski]

Move the macro definitions above the struct definitions and add some
tabs for better readability.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/misc/eeprom/at24.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 52875f4..0f873db 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -52,6 +52,14 @@
  * which won't work on pure SMBus systems.
  */
 
+#define AT24_SIZE_BYTELEN  5
+#define AT24_SIZE_FLAGS8
+
+#define AT24_BITMASK(x)(BIT(x) - 1)
+
+#define AT24CS_SERIAL_SIZE 16
+#define AT24CS_SERIAL_ADDR(addr)   (addr + 0x08)
+
 struct at24_data {
struct at24_platform_data chip;
struct memory_accessor macc;
@@ -98,14 +106,6 @@ static unsigned write_timeout = 25;
 module_param(write_timeout, uint, 0);
 MODULE_PARM_DESC(write_timeout, "Time (in ms) to try writes (default 25)");
 
-#define AT24_SIZE_BYTELEN 5
-#define AT24_SIZE_FLAGS 8
-
-#define AT24_BITMASK(x) (BIT(x) - 1)
-
-#define AT24CS_SERIAL_SIZE 16
-#define AT24CS_SERIAL_ADDR(addr) (addr + 0x08)
-
 /* create non-zero magic value for given eeprom parameters */
 #define AT24_DEVICE_MAGIC(_len, _flags)\
((1 << AT24_SIZE_FLAGS | (_flags))  \
-- 
2.1.4

--
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

[RESEND PATCH 7/9] eeprom: at24: add the at24cs series to the list of supported devices

[Bartosz Golaszewski]

The infrastructure for reading of the factory-programmed serial number
for at24cs EEPROM series is now in place. Add the chips that are actually
equipped with the serial number memory area to the list of supported
devices.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/misc/eeprom/at24.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 0d34b94..b5181a3 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -116,16 +116,25 @@ static const struct i2c_device_id at24_ids[] = {
{ "24c00",  AT24_DEVICE_MAGIC(128 / 8,  AT24_FLAG_TAKE8ADDR) },
/* old variants can't be handled with this generic entry! */
{ "24c01",  AT24_DEVICE_MAGIC(1024 / 8, 0) },
+   { "24cs01", AT24_DEVICE_MAGIC(1024 / 8, AT24_FLAG_SERIAL) },
{ "24c02",  AT24_DEVICE_MAGIC(2048 / 8, 0) },
+   { "24cs02", AT24_DEVICE_MAGIC(2048 / 8, AT24_FLAG_SERIAL) },
/* spd is a 24c02 in memory DIMMs */
{ "spd",AT24_DEVICE_MAGIC(2048 / 8,
AT24_FLAG_READONLY | AT24_FLAG_IRUGO) },
{ "24c04",  AT24_DEVICE_MAGIC(4096 / 8, 0) },
+   { "24cs04", AT24_DEVICE_MAGIC(4096 / 8, AT24_FLAG_SERIAL) },
/* 24rf08 quirk is handled at i2c-core */
{ "24c08",  AT24_DEVICE_MAGIC(8192 / 8, 0) },
+   { "24cs08", AT24_DEVICE_MAGIC(8192 / 8, AT24_FLAG_SERIAL) },
{ "24c16",  AT24_DEVICE_MAGIC(16384 / 8,0) },
+   { "24cs16", AT24_DEVICE_MAGIC(16384 / 8,AT24_FLAG_SERIAL) },
{ "24c32",  AT24_DEVICE_MAGIC(32768 / 8,AT24_FLAG_ADDR16) },
+   { "24cs32", AT24_DEVICE_MAGIC(32768 / 8,
+   AT24_FLAG_ADDR16 | AT24_FLAG_SERIAL) },
{ "24c64",  AT24_DEVICE_MAGIC(65536 / 8,AT24_FLAG_ADDR16) },
+   { "24cs64", AT24_DEVICE_MAGIC(65536 / 8,
+   AT24_FLAG_ADDR16 | AT24_FLAG_SERIAL) },
{ "24c128", AT24_DEVICE_MAGIC(131072 / 8,   AT24_FLAG_ADDR16) },
{ "24c256", AT24_DEVICE_MAGIC(262144 / 8,   AT24_FLAG_ADDR16) },
{ "24c512", AT24_DEVICE_MAGIC(524288 / 8,   AT24_FLAG_ADDR16) },
-- 
2.1.4

--
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

[RESEND PATCH 8/9] eeprom: at24: remove a reduntant if

[Bartosz Golaszewski]

It seems as if the second check for I2C_FUNC_I2C functionality had been
introduced accidentally during a merge. Tt's reduntant, so remove it.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/misc/eeprom/at24.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index b5181a3..52875f4 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -613,10 +613,7 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
} else {
return -EPFNOSUPPORT;
}
-   }
 
-   /* Use I2C operations unless we're stuck with SMBus extensions. */
-   if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
if (i2c_check_functionality(client->adapter,
I2C_FUNC_SMBUS_WRITE_I2C_BLOCK)) {
use_smbus_write = I2C_SMBUS_I2C_BLOCK_DATA;
-- 
2.1.4

--
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: pnx: fix warnings caused by enabling unprepared clock

[Shubhrajyoti Datta]

On Mon, Oct 19, 2015 at 11:49 PM, Vladimir Zapolskiy  wrote:
> On 19.10.2015 19:21, Shubhrajyoti Datta wrote:
>> On Sun, Oct 18, 2015 at 12:22 AM, Vladimir Zapolskiy  wrote:
>>> If common clock framework is configured, the driver generates a warning,
>>> which is fixed by this change:
>> Maybe just describe the issue and the fix.
>> Is it just a warning or  the clk enable doesn't work ?
>>
>> I feel the crash log in the commit msg is not very informative.
>
> It is not a crash, it is a WARN_ON(1) backtrace.

ok

>
> The backtrace is informative enough IMHO, because if you check the code
> around given drivers/clk/clk.c:727 you may find the rootcause, the
> WARN_ON() and that the clock is not enabled as a result.
>
> CLK_COMMON selects HAVE_CLK_PREPARE and all drivers used on platforms
> with common clock framework must have clk_prepare/clk_unprepare, this
> information is omitted as well-known.
>
> But if you insist, I will improve the commit message, I'm interested in
> applying this trivial fix as soon as possible, then concentrate on doing
> something more fascinating.

My request will be to describe the issue.
Like the probe fails or you access registers with clocks not enabled

Or it is a warning fix and the controller works etc.
>
>>>
--
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 v3 1/1] i2c: add ACPI support for I2C mux ports

[Andy Shevchenko]

+Cc: Ismo Puustinen

On Mon, 2015-10-19 at 15:29 -0700, Dustin Byford wrote:
> Although I2C mux devices are easily enumerated using ACPI (_HID/_CID
> or
> device property compatible string match) enumerating I2C client
> devices
> connected through a I2C mux device requires a little extra work.
> 
> This change implements a method for describing an I2C device
> hierarchy that
> includes mux devices by using an ACPI Device() for each mux channel
> along
> with an _ADR to set the channel number for the device.  See
> Documentation/acpi/i2c-muxes.txt for a simple example.

Ismo, can you test this patch on top of what you have to see if it goes
smoothly (no break of Galileo Gen2 support) ?

> 
> Signed-off-by: Dustin Byford 
> ---
>  Documentation/acpi/i2c-muxes.txt | 58
> 
>  drivers/i2c/i2c-core.c   | 15 +--
>  drivers/i2c/i2c-mux.c|  8 ++
>  include/linux/acpi.h |  6 +
>  4 files changed, 85 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/acpi/i2c-muxes.txt
> 
> diff --git a/Documentation/acpi/i2c-muxes.txt
> b/Documentation/acpi/i2c-muxes.txt
> new file mode 100644
> index 000..9fcc4f0
> --- /dev/null
> +++ b/Documentation/acpi/i2c-muxes.txt
> @@ -0,0 +1,58 @@
> +ACPI I2C Muxes
> +--
> +
> +Describing an I2C device hierarchy that includes I2C muxes requires
> an ACPI
> +Device () scope per mux channel.
> +
> +Consider this topology:
> +
> ++--+   +--+
> +| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
> +|  |   | 0x70 |--CH01--> i2c client B (0x50)
> ++--+   +--+
> +
> +which corresponds to the following ASL:
> +
> +Device (SMB1)
> +{
> +Name (_HID, ...)
> +Device (MUX0)
> +{
> +Name (_HID, ...)
> +Name (_CRS, ResourceTemplate () {
> +I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
> +  AddressingMode7Bit, "^SMB1", 0x00,
> +  ResourceConsumer,,)
> +}
> +
> +Device (CH00)
> +{
> +Name (_ADR, 0)
> +
> +Device (CLIA)
> +{
> +Name (_HID, ...)
> +Name (_CRS, ResourceTemplate () {
> +I2cSerialBus (0x50, ControllerInitiated,
> I2C_SPEED,
> +  AddressingMode7Bit, "^CH00", 0x00,
> +  ResourceConsumer,,)
> +}
> +}
> +}
> +
> +Device (CH01)
> +{
> +Name (_ADR, 1)
> +
> +Device (CLIB)
> +{
> +Name (_HID, ...)
> +Name (_CRS, ResourceTemplate () {
> +I2cSerialBus (0x50, ControllerInitiated,
> I2C_SPEED,
> +  AddressingMode7Bit, "^CH01", 0x00,
> +  ResourceConsumer,,)
> +}
> +}
> +}
> +}
> +}
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 579b99d..af0811c 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -156,7 +156,7 @@ static acpi_status
> acpi_i2c_add_device(acpi_handle handle, u32 level,
>   info.fwnode = acpi_fwnode_handle(adev);
>  
>   memset(, 0, sizeof(lookup));
> - lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
> + lookup.adapter_handle = ACPI_HANDLE(>dev);
>   lookup.device_handle = handle;
>   lookup.info = 
>  
> @@ -212,7 +212,7 @@ static void acpi_i2c_register_devices(struct
> i2c_adapter *adap)
>  {
>   acpi_status status;
>  
> - if (!adap->dev.parent || !has_acpi_companion(adap-
> >dev.parent))
> + if (!has_acpi_companion(>dev))
>   return;
>  
>   status = acpi_walk_namespace(ACPI_TYPE_DEVICE,
> ACPI_ROOT_OBJECT,
> @@ -1667,6 +1667,17 @@ int i2c_add_adapter(struct i2c_adapter
> *adapter)
>   struct device *dev = >dev;
>   int id;
>  
> + /*
> +  * By default, associate I2C adapters with their parent
> device's ACPI
> +  * node.
> +  */
> + if (!has_acpi_companion(dev)) {
> + struct acpi_device *adev = ACPI_COMPANION(dev-
> >parent);
> +
> + if (adev)
> + ACPI_COMPANION_SET(dev, adev);
> + }
> +
>   if (dev->of_node) {
>   id = of_alias_get_id(dev->of_node, "i2c");
>   if (id >= 0) {
> diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
> index 2ba7c0f..00fc5b1 100644
> --- a/drivers/i2c/i2c-mux.c
> +++ b/drivers/i2c/i2c-mux.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* multiplexer per channel data */
>  struct i2c_mux_priv {
> @@ -173,6 +174,13 @@ struct i2c_adapter *i2c_add_mux_adapter(struct
> i2c_adapter *parent,
>   }
>   }
>  
> + /*
> +  * Associate the mux channel with an ACPI node.
> +  */
> + if (has_acpi_companion(mux_dev))
> + 

[RESEND PATCH 1/9] eeprom: at24: platform_data: use BIT() macro

[Bartosz Golaszewski]

Use BIT() macro to replace the 0xXX constants in platform_data flags
definitions.

Signed-off-by: Bartosz Golaszewski 
---
 include/linux/platform_data/at24.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/platform_data/at24.h 
b/include/linux/platform_data/at24.h
index c42aa89..8d90f52 100644
--- a/include/linux/platform_data/at24.h
+++ b/include/linux/platform_data/at24.h
@@ -43,10 +43,10 @@ struct at24_platform_data {
u32 byte_len;   /* size (sum of all addr) */
u16 page_size;  /* for writes */
u8  flags;
-#define AT24_FLAG_ADDR16   0x80/* address pointer is 16 bit */
-#define AT24_FLAG_READONLY 0x40/* sysfs-entry will be read-only */
-#define AT24_FLAG_IRUGO0x20/* sysfs-entry will be 
world-readable */
-#define AT24_FLAG_TAKE8ADDR0x10/* take always 8 addresses (24c00) */
+#define AT24_FLAG_ADDR16   BIT(7)  /* address pointer is 16 bit */
+#define AT24_FLAG_READONLY BIT(6)  /* sysfs-entry will be read-only */
+#define AT24_FLAG_IRUGOBIT(5)  /* sysfs-entry will be 
world-readable */
+#define AT24_FLAG_TAKE8ADDRBIT(4)  /* take always 8 addresses (24c00) */
 
void(*setup)(struct memory_accessor *, void *context);
void*context;
-- 
2.1.4

--
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

[RESEND PATCH 0/9] eeprom: at24: at24cs series serial number read

[Bartosz Golaszewski]

Chips from the at24cs EEPROM series have an additional read-only memory area
containing a factory pre-programmed serial number. In order to access it, a
dummy write must be executed before reading the serial number bytes.

This series adds support for reading the serial number through a sysfs
attribute.

While we're at it: some of the patches contain readability tweaks and code
organization fixes.

Tested with at24cs64 and at24cs02 chips (for both 16 and 8 bit address
pointers).

Bartosz Golaszewski (9):
  eeprom: at24: platform_data: use BIT() macro
  eeprom: at24: new flag in platform_data
  eeprom: at24: tie up an additional address for at24cs series
  eeprom: at24: support reading of the serial number
  eeprom: at24: export the serial number through sysfs
  eeprom: at24: improve the device_id table readability
  eeprom: at24: add the at24cs series to the list of supported devices
  eeprom: at24: remove a reduntant if
  eeprom: at24: readability tweaks

 drivers/misc/eeprom/at24.c | 181 +++--
 include/linux/platform_data/at24.h |   9 +-
 2 files changed, 160 insertions(+), 30 deletions(-)

-- 
2.1.4

--
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

[RESEND PATCH 3/9] eeprom: at24: tie up an additional address for at24cs series

[Bartosz Golaszewski]

The at24cs series EEPROM chips have an additional read-only memory area,
that is visible on a different i2c slave address. Tie it up with a dummy
device.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/misc/eeprom/at24.c | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index c6cb7f8..3a75a52 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -102,6 +102,8 @@ MODULE_PARM_DESC(write_timeout, "Time (in ms) to try writes 
(default 25)");
 
 #define AT24_BITMASK(x) (BIT(x) - 1)
 
+#define AT24CS_SERIAL_ADDR(addr) (addr + 0x08)
+
 /* create non-zero magic value for given eeprom parameters */
 #define AT24_DEVICE_MAGIC(_len, _flags)\
((1 << AT24_SIZE_FLAGS | (_flags))  \
@@ -543,6 +545,8 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
 
if (chip.flags & AT24_FLAG_TAKE8ADDR)
num_addresses = 8;
+   else if (chip.flags & AT24_FLAG_SERIAL)
+   num_addresses = 2;
else
num_addresses = DIV_ROUND_UP(chip.byte_len,
(chip.flags & AT24_FLAG_ADDR16) ? 65536 : 256);
@@ -601,12 +605,30 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
at24->client[0] = client;
 
/* use dummy devices for multiple-address chips */
-   for (i = 1; i < num_addresses; i++) {
-   at24->client[i] = i2c_new_dummy(client->adapter,
+   if (at24->chip.flags & AT24_FLAG_TAKE8ADDR) {
+   for (i = 1; i < num_addresses; i++) {
+   at24->client[i] = i2c_new_dummy(client->adapter,
+   client->addr + i);
+   if (!at24->client[i]) {
+   dev_err(>dev,
+   "address 0x%02x unavailable\n",
client->addr + i);
-   if (!at24->client[i]) {
+   err = -EADDRINUSE;
+   goto err_clients;
+   }
+   }
+   }
+
+   /*
+* at24cs series tie up an additional address for the memory area
+* contining the serial number
+*/
+   if (at24->chip.flags & AT24_FLAG_SERIAL) {
+   at24->client[1] = i2c_new_dummy(client->adapter,
+   AT24CS_SERIAL_ADDR(client->addr));
+   if (!at24->client[1]) {
dev_err(>dev, "address 0x%02x unavailable\n",
-   client->addr + i);
+   AT24CS_SERIAL_ADDR(client->addr));
err = -EADDRINUSE;
goto err_clients;
}
-- 
2.1.4

--
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

[RESEND PATCH 4/9] eeprom: at24: support reading of the serial number

[Bartosz Golaszewski]

The at24cs series EEPROM chips have an additional read-only memory area
containing a factory pre-programmed serial number. In order to access
it, one has to perform a dummy write before reading the serial number
bytes.

Add a function that allows to access the serial number.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/misc/eeprom/at24.c | 65 ++
 1 file changed, 65 insertions(+)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 3a75a52..4d4a793 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -156,6 +156,71 @@ static struct i2c_client *at24_translate_offset(struct 
at24_data *at24,
return at24->client[i];
 }
 
+static int __attribute__((unused)) at24cs_eeprom_serial_read(
+   struct at24_data *at24,
+   char *buf, unsigned offset,
+   size_t count)
+{
+   unsigned long timeout, read_time;
+   struct i2c_client *client;
+   struct i2c_msg msg[2];
+   u8 addrbuf[2];
+   int status;
+
+   client = at24->client[1];
+
+   memset(msg, 0, sizeof(msg));
+   msg[0].addr = client->addr;
+   msg[0].buf = addrbuf;
+
+   /*
+* The address pointer of the device is shared between the regular
+* EEPROM array and the serial number block. The dummy write (part of
+* the sequential read protocol) ensures the address pointer is reset
+* to the desired position.
+*/
+   if (at24->chip.flags & AT24_FLAG_ADDR16) {
+   /*
+* For 16 bit address pointers, the word address must contain
+* a '10' sequence in bits 11 and 10 regardless of the
+* intended position of the address pointer.
+*/
+   addrbuf[0] = 0x08;
+   addrbuf[1] = offset;
+   msg[0].len = 2;
+   } else {
+   /*
+* Otherwise the word address must begin with a '10' sequence,
+* regardless of the intended address.
+*/
+   addrbuf[0] = 0x80 + offset;
+   msg[0].len = 1;
+   }
+
+   msg[1].addr = client->addr;
+   msg[1].flags = I2C_M_RD;
+   msg[1].buf = buf;
+   msg[1].len = count;
+
+   /*
+* Reads fail if the previous write didn't complete yet. We may
+* loop a few times until this one succeeds, waiting at least
+* long enough for one entire page write to work.
+*/
+   timeout = jiffies + msecs_to_jiffies(write_timeout);
+   do {
+   read_time = jiffies;
+   status = i2c_transfer(client->adapter, msg, 2);
+   if (status == 2)
+   return count;
+
+   /* REVISIT: at HZ=100, this is slw */
+   msleep(1);
+   } while (time_before(read_time, timeout));
+
+   return -ETIMEDOUT;
+}
+
 static ssize_t at24_eeprom_read(struct at24_data *at24, char *buf,
unsigned offset, size_t count)
 {
-- 
2.1.4

--
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

[RESEND PATCH 2/9] eeprom: at24: new flag in platform_data

[Bartosz Golaszewski]

In preparation for supporting the at24cs EEPROM series add a new flag to
platform data. When set, it should tell the driver that the chip has an
additional read-only memory area that holds a factory pre-programmed serial
number.

Signed-off-by: Bartosz Golaszewski 
---
 include/linux/platform_data/at24.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/platform_data/at24.h 
b/include/linux/platform_data/at24.h
index 8d90f52..5686f91 100644
--- a/include/linux/platform_data/at24.h
+++ b/include/linux/platform_data/at24.h
@@ -47,6 +47,7 @@ struct at24_platform_data {
 #define AT24_FLAG_READONLY BIT(6)  /* sysfs-entry will be read-only */
 #define AT24_FLAG_IRUGOBIT(5)  /* sysfs-entry will be 
world-readable */
 #define AT24_FLAG_TAKE8ADDRBIT(4)  /* take always 8 addresses (24c00) */
+#define AT24_FLAG_SERIAL   BIT(3)  /* factory-programmed serial number */
 
void(*setup)(struct memory_accessor *, void *context);
void*context;
-- 
2.1.4

--
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 v4 11/22] i2c: core: Probe i2c adapters and devices on demand

[Wolfram Sang]

On Mon, Sep 07, 2015 at 02:23:36PM +0200, Tomeu Vizoso wrote:
> When looking up an i2c adapter or device through its OF node, probe it
> if it hasn't already.
> 
> The goal is to reduce deferred probes to a minimum, as it makes it very
> cumbersome to find out why a device failed to probe, and can introduce
> very big delays in when a critical device is probed.
> 
> Signed-off-by: Tomeu Vizoso 

If the I2C part stays that simple and the core part of the series is
accepted, then:

Acked-by: Wolfram Sang 

Thanks,

   Wolfram



signature.asc
Description: Digital signature

Re: [PATCH 1/2] i2c: designware: register clkdev during acpi device configuration

[Mika Westerberg]

On Tue, Oct 20, 2015 at 02:38:01PM +0800, Ken Xue wrote:
> DW I2C driver tries to register a clk from id->driver_data as an
> alternative way besides intel lpss. But code doesn't register the
> clk to clkdev. So, devm_clk_get will fail during probe.
> 
> The patch can fix this issue.

Since you now have drivers/acpi/acpi_apd.c for AMD ACPI stuff, can you
create the clock there just like we do for Intel stuff?
--
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 v3 1/1] i2c: add ACPI support for I2C mux ports

[Mika Westerberg]

On Mon, Oct 19, 2015 at 03:29:00PM -0700, Dustin Byford wrote:
> Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
> device property compatible string match) enumerating I2C client devices
> connected through a I2C mux device requires a little extra work.
> 
> This change implements a method for describing an I2C device hierarchy that
> includes mux devices by using an ACPI Device() for each mux channel along
> with an _ADR to set the channel number for the device.  See
> Documentation/acpi/i2c-muxes.txt for a simple example.
> 
> Signed-off-by: Dustin Byford 

In general this looks good to me.

> ---
>  Documentation/acpi/i2c-muxes.txt | 58 
> 
>  drivers/i2c/i2c-core.c   | 15 +--
>  drivers/i2c/i2c-mux.c|  8 ++
>  include/linux/acpi.h |  6 +
>  4 files changed, 85 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/acpi/i2c-muxes.txt
> 

[...]

> + /*
> +  * By default, associate I2C adapters with their parent device's ACPI
> +  * node.
> +  */
> + if (!has_acpi_companion(dev)) {
> + struct acpi_device *adev = ACPI_COMPANION(dev->parent);
> +
> + if (adev)
> + ACPI_COMPANION_SET(dev, adev);

Instead of always doing this in the I2C core, maybe we can make it
dependent on the host controller driver. For example the I2C designware
driver already did this for both DT and ACPI:

adap->dev.parent = >dev;
adap->dev.of_node = pdev->dev.of_node;
ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));

Also I would like to ask what Rafael thinks about this since he authored
b34bb1ee71158d5b ("ACPI / I2C: Use parent's ACPI_HANDLE() in
acpi_i2c_register_devices()").

I don't see a problem multiple Linux devices sharing a single ACPI
companion device like in this patch but I may be forgetting something ;-)
--
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: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki  wrote:
> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse  
> >> wrote:
> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> >> > But the point I'm making is that we are working towards *fixing* that,
> >> >> > and *not* using DT-specific code in places where we should be using 
> >> >> > the
> >> >> > generic APIs.
> >> >>
> >> >> What is the plan for fixing things here?  It's not obvious (at least to
> >> >> me) that we don't want to have the subsystems having knowledge of how
> >> >> they are bound to a specific firmware which is what you seem to imply
> >> >> here.
> >> >
> >> > I don't know that there *is* a coherent plan here to address it all.
> >> >
> >> > Certainly, we *will* need subsystems to have firmware-specific
> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> >> > describe GPIO, and properties which reference GPIO pins are intended to
> >> > work through that — while in DT, properties which reference GPIO pins
> >> > will have different contents. They'll be compatible at the driver
> >> > level, in the sense that there's a call to get a given GPIO given the
> >> > property name, but the subsystems *will* be doing different things
> >> > behind the scenes.
> >> >
> >> > My plan, such as it is, is to go through the leaf-node drivers which
> >> > almost definitely *should* be firmware-agnostic, and convert those. And
> >> > then take stock of what we have left, and work out what, if anything,
> >> > still needs to be done.
> >>
> >> Many cases are already agnostic in the drivers in terms of the *_get()
> >> functions. Some are DT specific, but probably because those subsystems
> >> are new and DT only. In any case, I don't think these 1 line changes
> >> do anything to make doing conversions here harder.
> >>
> >> >> It seems like we're going to have to refactor these bits of code when
> >> >> they get generalised anyway so I'm not sure that the additional cost
> >> >> here is that big.
> >> >
> >> > That's an acceptable answer — "we're adding legacy code here but we
> >> > know it's going to be refactored anyway". If that's true, all it takes
> >> > is a note in the commit comment to that effect. That's different from
> >> > having not thought about it :)
> >>
> >> Considering at one point we did create a fwnode based API, we did
> >> think about it. Plus there was little input from ACPI folks as to
> >> whether the change was even useful for ACPI case.
> >
> > Well, sorry, but who was asking whom, specifically?
> 
> You and linux-acpi have been copied on v2 and later of the entire
> series I think.

Yes, but it wasn't like a direct request, say "We need your input, so can you
please have a look and BTW we want this in 4.4, so please do it ASAP".  In
which case I'd prioritize that before other things I needed to take care of.

> > The underlying problem is present in ACPI too and we don't really have a 
> > good
> > solution for it.  We might benefit from a common one if it existed.
> 
> The problem for DT is we don't generically know what are the
> dependencies at a core level. We could know some or most dependencies
> if phandles (links to other nodes) were typed, but they are not. If
> the core had this information, we could simply control the device
> creation to order probing. Instead, this information is encoded into
> the bindings and binding parsing resides in the subsystems. That
> parsing happens during probe of the client side and is done by the
> subsystems (for common bindings). Since we already do the parsing at
> this point, it is a convenient place to trigger the probe of the
> dependency. Is ACPI going to be similar in this regard?

It is similar in some ways.  For example, if a device's functionality depends
on an I2C resource (connection), the core doesn't know that at the device
creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.

There is a _DEP object in ACPI that can be used by firmware to tell the OS
about those dependencies, but there's no way in the driver core to use that
information anyway today.

> Fundamentally, it is a question of probe devices when their
> dependencies are present or drivers ensure their dependencies are
> ready. IIRC, init systems went thru a similar debate for service
> dependencies.

The probe ordering is not the entire picture, though.

Even if you get the probe ordering right, the problem is going to show up in
multiple other places: system suspend/resume, runtime PM, system shutdown,
unbinding of drivers.  In all of those cases it is necessary to handle things
in a specific order if there is a dependency.

> >> In any case, we're talking about adding 1 line.
> >
> > But also about making the driver core slighly OF-centric.
> 
> How so? The one line is in DT 

Re: [GIT PULL] On-demand device probing

[Rob Herring]

On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki  wrote:
> On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
>> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki  
>> wrote:
>> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
>> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse  
>> >> wrote:
>> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
>> >> >> > But the point I'm making is that we are working towards *fixing* 
>> >> >> > that,
>> >> >> > and *not* using DT-specific code in places where we should be using 
>> >> >> > the
>> >> >> > generic APIs.
>> >> >>
>> >> >> What is the plan for fixing things here?  It's not obvious (at least to
>> >> >> me) that we don't want to have the subsystems having knowledge of how
>> >> >> they are bound to a specific firmware which is what you seem to imply
>> >> >> here.
>> >> >
>> >> > I don't know that there *is* a coherent plan here to address it all.
>> >> >
>> >> > Certainly, we *will* need subsystems to have firmware-specific
>> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
>> >> > describe GPIO, and properties which reference GPIO pins are intended to
>> >> > work through that — while in DT, properties which reference GPIO pins
>> >> > will have different contents. They'll be compatible at the driver
>> >> > level, in the sense that there's a call to get a given GPIO given the
>> >> > property name, but the subsystems *will* be doing different things
>> >> > behind the scenes.
>> >> >
>> >> > My plan, such as it is, is to go through the leaf-node drivers which
>> >> > almost definitely *should* be firmware-agnostic, and convert those. And
>> >> > then take stock of what we have left, and work out what, if anything,
>> >> > still needs to be done.
>> >>
>> >> Many cases are already agnostic in the drivers in terms of the *_get()
>> >> functions. Some are DT specific, but probably because those subsystems
>> >> are new and DT only. In any case, I don't think these 1 line changes
>> >> do anything to make doing conversions here harder.
>> >>
>> >> >> It seems like we're going to have to refactor these bits of code when
>> >> >> they get generalised anyway so I'm not sure that the additional cost
>> >> >> here is that big.
>> >> >
>> >> > That's an acceptable answer — "we're adding legacy code here but we
>> >> > know it's going to be refactored anyway". If that's true, all it takes
>> >> > is a note in the commit comment to that effect. That's different from
>> >> > having not thought about it :)
>> >>
>> >> Considering at one point we did create a fwnode based API, we did
>> >> think about it. Plus there was little input from ACPI folks as to
>> >> whether the change was even useful for ACPI case.
>> >
>> > Well, sorry, but who was asking whom, specifically?
>>
>> You and linux-acpi have been copied on v2 and later of the entire
>> series I think.
>
> Yes, but it wasn't like a direct request, say "We need your input, so can you
> please have a look and BTW we want this in 4.4, so please do it ASAP".  In
> which case I'd prioritize that before other things I needed to take care of.

Fair enough. Can you please review and comment on v7 of the series? We
can discuss at KS as well.

>> > The underlying problem is present in ACPI too and we don't really have a 
>> > good
>> > solution for it.  We might benefit from a common one if it existed.
>>
>> The problem for DT is we don't generically know what are the
>> dependencies at a core level. We could know some or most dependencies
>> if phandles (links to other nodes) were typed, but they are not. If
>> the core had this information, we could simply control the device
>> creation to order probing. Instead, this information is encoded into
>> the bindings and binding parsing resides in the subsystems. That
>> parsing happens during probe of the client side and is done by the
>> subsystems (for common bindings). Since we already do the parsing at
>> this point, it is a convenient place to trigger the probe of the
>> dependency. Is ACPI going to be similar in this regard?
>
> It is similar in some ways.  For example, if a device's functionality depends
> on an I2C resource (connection), the core doesn't know that at the device
> creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.

So you will need to create devices, defer their probing and then probe
on demand as well unless you have other ideas how you would do it.

> There is a _DEP object in ACPI that can be used by firmware to tell the OS
> about those dependencies, but there's no way in the driver core to use that
> information anyway today.

I would think that the equivalent function for ACPI to of_device_probe
could process these if they are generic and you can associate the
dependency to a struct device.

>> Fundamentally, it is a question of probe devices when their
>> dependencies are present or drivers ensure 

[RESEND PATCH 3/4] i2c: rk3x: Fix module autoload for OF platform driver

[Luis de Bethencourt]

From: Luis de Bethencourt 

This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.

Signed-off-by: Luis de Bethencourt 
---
 drivers/i2c/busses/i2c-rk3x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 72e97e30..c1935eb 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -858,6 +858,7 @@ static const struct of_device_id rk3x_i2c_match[] = {
{ .compatible = "rockchip,rk3288-i2c", .data = (void *)_data[2] },
{},
 };
+MODULE_DEVICE_TABLE(of, rk3x_i2c_match);
 
 static int rk3x_i2c_probe(struct platform_device *pdev)
 {
-- 
2.5.3

--
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

[RESEND PATCH 2/4] i2c: meson: Fix module autoload for OF platform driver

[Luis de Bethencourt]

From: Luis de Bethencourt 

This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.

Signed-off-by: Luis de Bethencourt 
---
 drivers/i2c/busses/i2c-meson.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/busses/i2c-meson.c b/drivers/i2c/busses/i2c-meson.c
index 5e176ad..71d3929 100644
--- a/drivers/i2c/busses/i2c-meson.c
+++ b/drivers/i2c/busses/i2c-meson.c
@@ -475,6 +475,7 @@ static const struct of_device_id meson_i2c_match[] = {
{ .compatible = "amlogic,meson6-i2c" },
{ },
 };
+MODULE_DEVICE_TABLE(of, meson_i2c_match);
 
 static struct platform_driver meson_i2c_driver = {
.probe   = meson_i2c_probe,
-- 
2.5.3

--
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

[RESEND PATCH 0/4] i2c: Fix module autoload for OF platform drivers

[Luis de Bethencourt]

Hello,

This is a resend of this patch series. It was posted on September 17. [0]

These patches add the missing MODULE_DEVICE_TABLE() for OF to export
the information so modules have the correct aliases built-in and
autoloading works correctly.

A longer explanation by Javier Canillas can be found here:
https://lkml.org/lkml/2015/7/30/519

The 4th patch of the series is Acked-by Linus Walleij.

[0] https://lkml.org/lkml/2015/9/17/558
[1] https://lkml.org/lkml/2015/9/17/559
[2] https://lkml.org/lkml/2015/9/17/560
[3] https://lkml.org/lkml/2015/9/17/561
[4] https://lkml.org/lkml/2015/9/17/562

Thanks,
Luis

Luis de Bethencourt (4):
  i2c: ibm-iic: Fix module autoload for OF platform driver
  i2c: meson: Fix module autoload for OF platform driver
  i2c: rk3x: Fix module autoload for OF platform driver
  i2c: stu300: Fix module autoload for OF platform driver

 drivers/i2c/busses/i2c-ibm_iic.c | 1 +
 drivers/i2c/busses/i2c-meson.c   | 1 +
 drivers/i2c/busses/i2c-rk3x.c| 1 +
 drivers/i2c/busses/i2c-stu300.c  | 1 +
 4 files changed, 4 insertions(+)

-- 
2.5.3

--
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

[RESEND PATCH 1/4] i2c: ibm-iic: Fix module autoload for OF platform driver

[Luis de Bethencourt]

From: Luis de Bethencourt 

This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.

Signed-off-by: Luis de Bethencourt 
---
 drivers/i2c/busses/i2c-ibm_iic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index 722f839..ab49230 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -798,6 +798,7 @@ static const struct of_device_id ibm_iic_match[] = {
{ .compatible = "ibm,iic", },
{}
 };
+MODULE_DEVICE_TABLE(of, ibm_iic_match);
 
 static struct platform_driver ibm_iic_driver = {
.driver = {
-- 
2.5.3

--
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 v3 1/6] i2c / ACPI: Rework I2C device scanning

[Wolfram Sang]

On Wed, Oct 07, 2015 at 01:18:44PM +0300, Andy Shevchenko wrote:
> From: Mika Westerberg 
> 
> The way we currently scan I2C devices behind an I2C host controller does not
> work in cases where the I2C device in question is not declared directly below
> the host controller ACPI node.
> 
> This is perfectly legal according the ACPI 6.0 specification and some existing
> systems are doing this.
> 
> To be able to enumerate all devices which are connected to a certain I2C host
> controller we need to rework the current I2C scanning routine a bit. Instead 
> of
> scanning directly below the host controller we scan the whole ACPI namespace
> for present devices with valid I2cSerialBus() connection pointing to the host
> controller in question.
> 
> Signed-off-by: Mika Westerberg 
> Acked-by: Rafael J. Wysocki 
> Signed-off-by: Andy Shevchenko 

Applied to for-next, thanks!

I am going to pick up patch 5 as well. I hope the others can go via mfd
and there is no build dependency on them?



signature.asc
Description: Digital signature

Re: [PATCH v3 5/6] at24: enable ACPI device found on Galileo Gen2

[Wolfram Sang]

On Wed, Oct 07, 2015 at 01:18:48PM +0300, Andy Shevchenko wrote:
> There is a 24c08 chip connected to i2c bus on Intel Galileo Gen2 board. Enable
> it via ACPI ID INT3499.
> 
> Signed-off-by: Andy Shevchenko 

Sparse rightfully says:

drivers/misc/eeprom/at24.c:491:53: warning: symbol 'id' shadows an earlier one
drivers/misc/eeprom/at24.c:474:50: originally declared here



signature.asc
Description: Digital signature

[RESEND PATCH 4/4] i2c: stu300: Fix module autoload for OF platform driver

[Luis de Bethencourt]

From: Luis de Bethencourt 

This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.

Signed-off-by: Luis de Bethencourt 
Acked-by: Linus Walleij 
---
 drivers/i2c/busses/i2c-stu300.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/busses/i2c-stu300.c b/drivers/i2c/busses/i2c-stu300.c
index 4885da9..460c134 100644
--- a/drivers/i2c/busses/i2c-stu300.c
+++ b/drivers/i2c/busses/i2c-stu300.c
@@ -977,6 +977,7 @@ static const struct of_device_id stu300_dt_match[] = {
{ .compatible = "st,ddci2c" },
{},
 };
+MODULE_DEVICE_TABLE(of, stu300_dt_match);
 
 static struct platform_driver stu300_i2c_driver = {
.driver = {
-- 
2.5.3

--
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

[PATCH] i2c: mv64xxx: really allow I2C offloading

[Thomas Petazzoni]

From: Hezi 

Commit 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix
several problems") completely reworked the offload support, but
stupidly left a debugging-related "return false" at the beginning of
the mv64xxx_i2c_can_offload() function. This has the unfortunate
consequence that offloading is in fact never used, which wasn't really
the intention.

This commit fixes that problem by removing the stupid "return false".

Fixes: 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix several 
problems")
Cc: 
Signed-off-by: Hezi 
[Thomas: reworked commit log and title.]
Signed-off-by: Thomas Petazzoni 
---
Note: the original fix is from Hezi, but I rewrote the commit log,
which is why I authorized myself to treat my own work as being
"stupid". Which it really was.
---
 drivers/i2c/busses/i2c-mv64xxx.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 30059c1..5801227 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -669,8 +669,6 @@ mv64xxx_i2c_can_offload(struct mv64xxx_i2c_data *drv_data)
struct i2c_msg *msgs = drv_data->msgs;
int num = drv_data->num_msgs;
 
-   return false;
-
if (!drv_data->offload_enabled)
return false;
 
-- 
2.6.2

--
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: [GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Rob Herring wrote:

> > The probe ordering is not the entire picture, though.
> >
> > Even if you get the probe ordering right, the problem is going to show up in
> > multiple other places: system suspend/resume, runtime PM, system shutdown,
> > unbinding of drivers.  In all of those cases it is necessary to handle 
> > things
> > in a specific order if there is a dependency.
> 
> My understanding was with deferred probe that it also solves suspend
> ordering problems because things are suspended in reverse order of
> probing.

Devices are suspended in reverse order of _registration_.  Not of 
probing.

Furthermore, that applies only to devices that use synchronous suspend.  
Async suspend is becoming common, and there the only restrictions are 
parent-child relations plus whatever explicit requirements that drivers 
impose by calling device_pm_wait_for_dev().

Alan Stern

--
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 2/6] i2c: ismt: PCI core handles power state for us

[Wolfram Sang]

On Wed, Sep 16, 2015 at 05:23:59PM +0300, Andy Shevchenko wrote:
> There is no need to repeat the work that is already done in the PCI driver
> core. Remove suspend and resume callbacks.
> 
> Note that there is no more calls performed to enable or disable a PCI
> device during suspend-resume cycle. Nowadays they seems to be
> superflous. Someone can read more in [1].
> 
> [1] https://www.kernel.org/doc/ols/2009/ols2009-pages-319-330.pdf
> 
> Signed-off-by: Andy Shevchenko 

Checkpatch said:

WARNING: 'superflous' may be misspelled - perhaps 'superfluous'?
#6: 
superflous. Someone can read more in [1].

total: 0 errors, 1 warnings, 0 checks, 44 lines checked

Fixed it here.



signature.asc
Description: Digital signature

Re: [PATCH 1/6] i2c: ismt: improve usage of devres API

[Wolfram Sang]

On Mon, Sep 28, 2015 at 02:01:54PM +0300, Mika Westerberg wrote:
> On Mon, Sep 28, 2015 at 01:45:32PM +0300, Andy Shevchenko wrote:
> > On Wed, 2015-09-16 at 17:23 +0300, Andy Shevchenko wrote:
> > > pcim_release() will release any requested region. There is no need to 
> > > duplicate
> > > this effort in the driver.
> > 
> > Any comments on that clean up series?
> 
> FWIW the whole series looks good to me,
> 
> Reviewed-by: Mika Westerberg 

Applied all to for-next, thanks!




signature.asc
Description: Digital signature

Re: [PATCH] i2c: tegra: drop duplicated code for assigning algo

[Wolfram Sang]

> @@ -825,7 +825,6 @@ static int tegra_i2c_probe(struct platform_device *pdev)
>   i2c_dev->adapter.class = I2C_CLASS_DEPRECATED;
>   strlcpy(i2c_dev->adapter.name, "Tegra I2C adapter",
>   sizeof(i2c_dev->adapter.name));
> - i2c_dev->adapter.algo = _i2c_algo;
>   i2c_dev->adapter.dev.parent = >dev;
>   i2c_dev->adapter.nr = pdev->id;
>   i2c_dev->adapter.dev.of_node = pdev->dev.of_node;

I think it would be more consistent to keep this one and move the quirk
assignment also down here; then all adapter assignments are in one
place.



signature.asc
Description: Digital signature

Re: [REPOST PATCH v2] i2c-ocores: support big-endian register layout

[Wolfram Sang]

On Wed, Oct 07, 2015 at 02:45:11AM +0300, Max Filippov wrote:
> This allows using OpenCores I2C controller attached to its host in
> native-endian mode with bi-endian CPUs. Example of such system is Xtensa
> XTFPGA platform.
> 
> Acked-by: Peter Korsgaard 
> Signed-off-by: Max Filippov 

Applied to for-next, thanks!



signature.asc
Description: Digital signature

Re: [PATCH v2 6/6] i2c: designware: Move common probe code into i2c_dw_probe()

[Wolfram Sang]

On Mon, Oct 12, 2015 at 04:55:35PM +0300, Jarkko Nikula wrote:
> There is some code duplication in i2c-designware-platdrv and
> i2c-designware-pcidrv probe functions. What is even worse that duplication
> requires i2c_dw_xfer(), i2c_dw_func() and i2c_dw_isr() i2c-designware-core
> functions to be exported.
> 
> Therefore move common code into new i2c_dw_probe() and make functions above
> local to i2c-designware-core.
> 
> While merging the code patch does following functional changes:
> 
> - I2C Adapter name will be "Synopsys DesignWare I2C adapter". Previously it
>   was used for platform and ACPI devices but PCI device used
>   "i2c-designware-pci".
> - Using device name for interrupt name. Previous it was platform device name,
>   ACPI device name or "i2c-designware-pci".
> - Error code from devm_request_irq() and i2c_add_numbered_adapter() will be
>   printed in case of error.
> 
> Signed-off-by: Jarkko Nikula 

There was a merge conflict with a bugfix from i2c/for-current. I think
it is okay, but you may want to double check my i2c/for-next.

What about this irq-clearing-in-probe thingie on top of this series? :)



signature.asc
Description: Digital signature

[PATCH] i2c: busses: Use setup_timer

[Muhammad Falak R Wani]

Use timer API function setup_timer instead of init_timer to
initialize the timer.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/i2c/busses/i2c-pnx.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-pnx.c b/drivers/i2c/busses/i2c-pnx.c
index e814a36..cdbf632 100644
--- a/drivers/i2c/busses/i2c-pnx.c
+++ b/drivers/i2c/busses/i2c-pnx.c
@@ -659,9 +659,8 @@ static int i2c_pnx_probe(struct platform_device *pdev)
if (IS_ERR(alg_data->clk))
return PTR_ERR(alg_data->clk);
 
-   init_timer(_data->mif.timer);
-   alg_data->mif.timer.function = i2c_pnx_timeout;
-   alg_data->mif.timer.data = (unsigned long)alg_data;
+   setup_timer(_data->mif.timer, i2c_pnx_timeout,
+   (unsigned long)alg_data);
 
snprintf(alg_data->adapter.name, sizeof(alg_data->adapter.name),
 "%s", pdev->name);
-- 
1.9.1

--
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: [GIT PULL] On-demand device probing

[Mark Brown]

On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> On Tue, 20 Oct 2015, Tomeu Vizoso wrote:

> > This iteration of the series would make this quite easy, as
> > dependencies are calculated before probes are attempted:

> > https://lkml.org/lkml/2015/6/17/311

> But what Rafael is proposing is quite general; it would apply to _all_
> dependencies as opposed to just those present in DT drivers or those 
> affecting platform_devices.

We'll still need most of the DT bits that are there at the minute (the
ones strewn around the subsystems) AFAICT since it's at the point where
we parse the DT and work out what the dependencies are which we probably
want to do prior to getting the drivers up and will be different for
ACPI.  I think the level of DT dependency here looks a lot larger than
it actually is due to the fact that a lot of what's being modified is DT
parsing code.


signature.asc
Description: PGP signature

Re: [PATCH] i2c: mv64xxx: really allow I2C offloading

[Thomas Petazzoni]

Hello,

On Tue, 20 Oct 2015 16:56:21 +, Hezi Shahmoon wrote:
> Hi.
> 
> It is:
> Hezi Shahmoon
> 
> Email:
> h...@marvell.com

Thanks Hezi.

Wolfram, do you want me to send a v2 with Hezi's full name or will you
fix that up when applying the patch ?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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: i2c-au1550: relax bus timings a bit

[Manuel Lauss]

On Tue, Oct 20, 2015 at 5:44 PM, Wolfram Sang  wrote:
> Since you have access to these platforms, there is a pending devm
> conversion patchneeding some testing:
>
> http://patchwork.ozlabs.org/patch/482140/
>
> Are you maybe interested in checking that one?

Sure,  I've run-tested it now on the DB1300 board, no problems.
Tested-by: Manuel Lauss 

Thanks!
Manuel
--
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 v3 1/1] i2c: add ACPI support for I2C mux ports

[Dustin Byford]

Hi Mika,

On Tue Oct 20 15:51, Mika Westerberg wrote:
> On Mon, Oct 19, 2015 at 03:29:00PM -0700, Dustin Byford wrote:
> > Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
> > device property compatible string match) enumerating I2C client devices
> > connected through a I2C mux device requires a little extra work.
> > 
> > This change implements a method for describing an I2C device hierarchy that
> > includes mux devices by using an ACPI Device() for each mux channel along
> > with an _ADR to set the channel number for the device.  See
> > Documentation/acpi/i2c-muxes.txt for a simple example.
> > 
> > Signed-off-by: Dustin Byford 
> 
> In general this looks good to me.
> 
> > ---
> >  Documentation/acpi/i2c-muxes.txt | 58 
> > 
> >  drivers/i2c/i2c-core.c   | 15 +--
> >  drivers/i2c/i2c-mux.c|  8 ++
> >  include/linux/acpi.h |  6 +
> >  4 files changed, 85 insertions(+), 2 deletions(-)
> >  create mode 100644 Documentation/acpi/i2c-muxes.txt
> > 
> 
> [...]
> 
> > +   /*
> > +* By default, associate I2C adapters with their parent device's ACPI
> > +* node.
> > +*/
> > +   if (!has_acpi_companion(dev)) {
> > +   struct acpi_device *adev = ACPI_COMPANION(dev->parent);
> > +
> > +   if (adev)
> > +   ACPI_COMPANION_SET(dev, adev);
> 
> Instead of always doing this in the I2C core, maybe we can make it
> dependent on the host controller driver. For example the I2C designware
> driver already did this for both DT and ACPI:

I considered it, but I thought a default that fairly closely matches the
old behavior was more convenient.

On the other hand, leaving it up to the controllers makes it all very
explicit and perhaps simpler to reason about.


I could be convinced either way.  But, if we move it to the controller
drivers, which ones need the change?

grep -i acpi drivers/i2c/busses/i2c*

shows 18 drivers that might care.

>   adap->dev.parent = >dev;
>   adap->dev.of_node = pdev->dev.of_node;
>   ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));

Interesting, this code isn't in my tree.  I wonder why it was added,
what code looks at the acpi companion on the i2c dev?  Before my change
it was supposed to be NULL, and it is NULL on every other controller.

> Also I would like to ask what Rafael thinks about this since he authored
> b34bb1ee71158d5b ("ACPI / I2C: Use parent's ACPI_HANDLE() in
> acpi_i2c_register_devices()").
> 
> I don't see a problem multiple Linux devices sharing a single ACPI
> companion device like in this patch but I may be forgetting something ;-)

OK.  Thanks.

--Dustin
--
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: [GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Mark Brown wrote:

> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> 
> > Furthermore, that applies only to devices that use synchronous suspend.  
> > Async suspend is becoming common, and there the only restrictions are 
> > parent-child relations plus whatever explicit requirements that drivers 
> > impose by calling device_pm_wait_for_dev().
> 
> Hrm, this is the first I'd noticed that feature though I see the initial
> commit dates from January.

Async suspend and device_pm_wait_for_dev() were added in January 2010, 
not 2015!

>  It looks like most of the users are PCs at
> the minute but we should be using it more widely for embedded things,
> there's definitely some cases I'm aware of where it will allow us to
> remove some open coding.
> 
> It does seem like we want to be feeding dependency information we
> discover for probing way into the suspend dependencies...

Rafael has been thinking about a way to do this systematically.  
Nothing concrete has emerged yet.

Alan Stern

--
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: [GIT PULL] On-demand device probing

[Alan Stern]

On Tue, 20 Oct 2015, Tomeu Vizoso wrote:

> On 20 October 2015 at 18:04, Alan Stern  wrote:
> > On Tue, 20 Oct 2015, Mark Brown wrote:
> >
> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >>
> >> > Furthermore, that applies only to devices that use synchronous suspend.
> >> > Async suspend is becoming common, and there the only restrictions are
> >> > parent-child relations plus whatever explicit requirements that drivers
> >> > impose by calling device_pm_wait_for_dev().
> >>
> >> Hrm, this is the first I'd noticed that feature though I see the initial
> >> commit dates from January.
> >
> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
> > not 2015!
> >
> >>  It looks like most of the users are PCs at
> >> the minute but we should be using it more widely for embedded things,
> >> there's definitely some cases I'm aware of where it will allow us to
> >> remove some open coding.
> >>
> >> It does seem like we want to be feeding dependency information we
> >> discover for probing way into the suspend dependencies...
> >
> > Rafael has been thinking about a way to do this systematically.
> > Nothing concrete has emerged yet.
> 
> This iteration of the series would make this quite easy, as
> dependencies are calculated before probes are attempted:
> 
> https://lkml.org/lkml/2015/6/17/311

But what Rafael is proposing is quite general; it would apply to _all_
dependencies as opposed to just those present in DT drivers or those 
affecting platform_devices.

Alan Stern

--
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: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)

[Russell King - ARM Linux]

On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
> 
> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
>  wrote:
> >> > What you can do is print those devices which have failed to probe at
> >> > late_initcall() time - possibly augmenting that with reports from
> >> > subsystems showing what resources are not available, but that's only
> >> > a guide, because of the "it might or might not be in a kernel module"
> >> > problem.
> >>
> >> Well, adding those reports would give you a changelog similar to the
> >> one in this series...
> >
> > I'm not sure about that, because what I was thinking of is adding
> > a flag which would be set at late_initcall() time prior to running
> > a final round of deferred device probing.
> 
> Which round is the final round?
> That's the one which didn't manage to bind any new devices to drivers,
> which is something you only know _after_ the round has been run.
> 
> So I think we need one extra round to handle this.
> 
> > This flag would then be used in a deferred_warn() printk function
> > which would normally be silent, but when this flag is set, it would
> > print the reason for the deferral - and this would replace (or be
> > added) to the subsystems and drivers which return -EPROBE_DEFER.
> >
> > That has the effect of hiding all the deferrals up until just before
> > launching into userspace, which should then acomplish two things -
> > firstly, getting rid of the rather useless deferred messages up to
> > that point, and secondly printing the reason why the remaining
> > deferrals are happening.
> >
> > That should be a small number of new lines plus a one-line change
> > in subsystems and drivers.
> 
> Apart from the extra round we probably can't get rid of, that sounds OK to me.

Something like this.  I haven't put a lot of effort into it to change all
the places which return an -EPROBE_DEFER, and it also looks like we need
some helpers to report when we have only an device_node (or should that
be fwnode?)  See the commented out of_warn_deferred() in
drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
for resources should make debugging why things are getting deferred easier.

We could make driver_deferred_probe_report something that can be
deactivated again after the last deferred probe run, and provide the
user with a knob that they can turn it back on again.

I've tried this out on two of my platforms, including forcing
driver_deferred_probe_report to be enabled, and I get exactly one
deferred probe, so not a particularly good test.

The patch won't apply as-is to mainline for all files; it's based on my
tree which has some 360 additional patches (which seems to be about
normal for my tree now.)

 drivers/base/dd.c   | 29 +
 drivers/base/power/domain.c |  7 +--
 drivers/clk/clkdev.c|  9 -
 drivers/gpio/gpiolib-of.c   |  5 +
 drivers/gpu/drm/bridge/dw_hdmi.c|  2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
 drivers/gpu/drm/imx/imx-ldb.c   |  5 +++--
 drivers/gpu/drm/msm/dsi/dsi.c   |  2 +-
 drivers/gpu/drm/msm/msm_drv.c   |  3 ++-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
 drivers/of/irq.c|  5 -
 drivers/pci/host/pci-mvebu.c|  1 +
 drivers/pinctrl/core.c  |  5 +++--
 drivers/pinctrl/devicetree.c|  4 ++--
 drivers/regulator/core.c|  5 +++--
 include/linux/device.h  |  1 +
 16 files changed, 71 insertions(+), 17 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index be0eb4639128..bb12224f2901 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev)
mutex_unlock(_probe_mutex);
 }
 
+static bool driver_deferred_probe_report;
+
+/**
+ * dev_warn_deferred() - report why a probe has been deferred
+ */
+void dev_warn_deferred(struct device *dev, const char *fmt, ...)
+{
+   if (driver_deferred_probe_report) {
+   struct va_format vaf;
+   va_list ap;
+
+   va_start(ap, fmt);
+   vaf.fmt = fmt;
+   vaf.va = 
+
+   dev_warn(dev, "deferring probe: %pV", );
+   va_end(ap);
+   }
+}
+EXPORT_SYMBOL_GPL(dev_warn_deferred);
+
 static bool driver_deferred_probe_enable = false;
+
 /**
  * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
  *
@@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
driver_deferred_probe_trigger();
/* Sort as many dependencies as possible before exiting initcalls */
flush_workqueue(deferred_wq);
+
+   /* Now one final round, reporting any devices that remain deferred */
+   driver_deferred_probe_report = true;
+   driver_deferred_probe_trigger();
+   /* Sort as many 

Re: [linux-sunxi] [PATCH] i2c: mv64xxx: The n clockdiv factor is 0 based on sunxi SoCs

[Wolfram Sang]

> WIth Hans having figured it out and fixing it, I'll absolutly will take a
> nother look and check with a scope if it all works out now.

Have you done this already? /me is always looking for Tested-by: tags :)



signature.asc
Description: Digital signature

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 20 October 2015 at 18:04, Alan Stern  wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
>
>> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>>
>> > Furthermore, that applies only to devices that use synchronous suspend.
>> > Async suspend is becoming common, and there the only restrictions are
>> > parent-child relations plus whatever explicit requirements that drivers
>> > impose by calling device_pm_wait_for_dev().
>>
>> Hrm, this is the first I'd noticed that feature though I see the initial
>> commit dates from January.
>
> Async suspend and device_pm_wait_for_dev() were added in January 2010,
> not 2015!
>
>>  It looks like most of the users are PCs at
>> the minute but we should be using it more widely for embedded things,
>> there's definitely some cases I'm aware of where it will allow us to
>> remove some open coding.
>>
>> It does seem like we want to be feeding dependency information we
>> discover for probing way into the suspend dependencies...
>
> Rafael has been thinking about a way to do this systematically.
> Nothing concrete has emerged yet.

This iteration of the series would make this quite easy, as
dependencies are calculated before probes are attempted:

https://lkml.org/lkml/2015/6/17/311

Regards,

Tomeu

> Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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: mv64xxx: really allow I2C offloading

[Wolfram Sang]

On Tue, Oct 20, 2015 at 04:32:24PM +0200, Thomas Petazzoni wrote:
> From: Hezi 

Is "Hezi" the full name?

> 
> Commit 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix
> several problems") completely reworked the offload support, but
> stupidly left a debugging-related "return false" at the beginning of
> the mv64xxx_i2c_can_offload() function. This has the unfortunate
> consequence that offloading is in fact never used, which wasn't really
> the intention.
> 
> This commit fixes that problem by removing the stupid "return false".
> 
> Fixes: 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix several 
> problems")
> Cc: 
> Signed-off-by: Hezi 
> [Thomas: reworked commit log and title.]
> Signed-off-by: Thomas Petazzoni 
> ---
> Note: the original fix is from Hezi, but I rewrote the commit log,
> which is why I authorized myself to treat my own work as being
> "stupid". Which it really was.

:)

> ---
>  drivers/i2c/busses/i2c-mv64xxx.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-mv64xxx.c 
> b/drivers/i2c/busses/i2c-mv64xxx.c
> index 30059c1..5801227 100644
> --- a/drivers/i2c/busses/i2c-mv64xxx.c
> +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> @@ -669,8 +669,6 @@ mv64xxx_i2c_can_offload(struct mv64xxx_i2c_data *drv_data)
>   struct i2c_msg *msgs = drv_data->msgs;
>   int num = drv_data->num_msgs;
>  
> - return false;
> -
>   if (!drv_data->offload_enabled)
>   return false;
>  
> -- 
> 2.6.2
> 


signature.asc
Description: Digital signature

Re: [PATCH v2] i2c: davinci: Optimize clock generation on Keystone SoC

[Wolfram Sang]

On Mon, Sep 14, 2015 at 11:03:50AM +0200, Alexander Sverdlin wrote:
> According to "KeyStone Architecture Inter-IC Control Bus User Guide", fixed
> additive part of frequency divisors (referred as "d" in the code and 
> datasheet)
> always equals to 6, independent of module clock prescaler.
> 
>  module clock frequency

Applied to for-next, thanks!



signature.asc
Description: Digital signature

Re: [PATCH v2] dts: keystone: Use new "ti,keystone-i2c" compatible

[Wolfram Sang]

On Mon, Sep 14, 2015 at 11:07:02AM +0200, Alexander Sverdlin wrote:
> Now as "i2c-davinci" driver has special handling for Keystone it's time to 
> switch
> the device tree to use new "compatible" property. Old one is left for 
> backwards-
> compatibility.
> 
> Signed-off-by: Alexander Sverdlin 

Shall I take this one or shall it go via the davinci tree?



signature.asc
Description: Digital signature

Re: [RESEND PATCH 1/3] i2c: added FUNC flag for unsupported clock stretching

[Wolfram Sang]

On Wed, Sep 16, 2015 at 03:32:01PM +0200, Nicola Corna wrote:
> Added I2C_FUNC_NO_CLK_STRETCH, to be used when clock stretching is not
> supported.
> 
> Signed-off-by: Nicola Corna 

I think this should be rather a quirk than a functionality, i.e.
I2C_AQ_NO_CLK_STRETCH. Agree?

> ---
>  Documentation/i2c/functionality | 1 +
>  include/uapi/linux/i2c.h| 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality
> index 4aae8ed..f53807e 100644
> --- a/Documentation/i2c/functionality
> +++ b/Documentation/i2c/functionality
> @@ -21,6 +21,7 @@ For the most up-to-date list of functionality constants, 
> please check
>I2C_M_REV_DIR_ADDR and I2C_M_NO_RD_ACK
>flags (which modify the I2C protocol!)
>I2C_FUNC_NOSTARTCan skip repeated start sequence
> +  I2C_FUNC_NO_CLK_STRETCH Does NOT support clock stretching
>I2C_FUNC_SMBUS_QUICKHandles the SMBus write_quick command
>I2C_FUNC_SMBUS_READ_BYTEHandles the SMBus read_byte command
>I2C_FUNC_SMBUS_WRITE_BYTE   Handles the SMBus write_byte command
> diff --git a/include/uapi/linux/i2c.h b/include/uapi/linux/i2c.h
> index b0a7dd6..59e4b43 100644
> --- a/include/uapi/linux/i2c.h
> +++ b/include/uapi/linux/i2c.h
> @@ -88,6 +88,7 @@ struct i2c_msg {
>  #define I2C_FUNC_SMBUS_PEC   0x0008
>  #define I2C_FUNC_NOSTART 0x0010 /* I2C_M_NOSTART */
>  #define I2C_FUNC_SLAVE   0x0020
> +#define I2C_FUNC_NO_CLK_STRETCH  0x0040 /* No check for SCL 
> low */
>  #define I2C_FUNC_SMBUS_BLOCK_PROC_CALL   0x8000 /* SMBus 2.0 */
>  #define I2C_FUNC_SMBUS_QUICK 0x0001
>  #define I2C_FUNC_SMBUS_READ_BYTE 0x0002
> -- 
> 2.5.1
> 


signature.asc
Description: Digital signature

Re: [GIT PULL] On-demand device probing

[Mark Brown]

On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:

> Furthermore, that applies only to devices that use synchronous suspend.  
> Async suspend is becoming common, and there the only restrictions are 
> parent-child relations plus whatever explicit requirements that drivers 
> impose by calling device_pm_wait_for_dev().

Hrm, this is the first I'd noticed that feature though I see the initial
commit dates from January.  It looks like most of the users are PCs at
the minute but we should be using it more widely for embedded things,
there's definitely some cases I'm aware of where it will allow us to
remove some open coding.

It does seem like we want to be feeding dependency information we
discover for probing way into the suspend dependencies...


signature.asc
Description: PGP signature

Re: [PATCH] i2c: i2c-au1550: relax bus timings a bit

[Wolfram Sang]

On Tue, Sep 08, 2015 at 08:56:23AM +0200, Manuel Lauss wrote:
> The i2c-au1550 driver has to program various setup and hold times
> for the sda/scl signals by hand.  The current values seem to be
> working best when the driver is supplied with 50MHz, however on the
> DB1300 board 48MHz is the closest we can get to it, and the timings
> are a bit too tight for that, leading to the last bit of a transmission
> sometimes being swallowed.  This manifests itself in wrong readings
> of the ne1619 sensor and inability to configure the wm8731 i2s codec.
> 
> With the relaxed timings, both the sensor and the i2s codec can now
> be accessed more reliably over a wider range of I2C block input
> frequencies.
> 
> Verified on DB1200, DB1300 and DB1550 boards.
> 
> Signed-off-by: Manuel Lauss 

Applied to for-next, thanks!

Since you have access to these platforms, there is a pending devm
conversion patchneeding some testing:

http://patchwork.ozlabs.org/patch/482140/

Are you maybe interested in checking that one?



signature.asc
Description: Digital signature

Re: [PATCH V5 1/6] i2c: Add i2c support to Freescale Layerscape platforms

[Wolfram Sang]

On Mon, Oct 19, 2015 at 07:56:09PM +0800, Zhiqiang Hou wrote:
> From: Shaohui Xie 
> 
> Modify the I2C_IMX config to support to Layerscape platforms.
> 
> Signed-off-by: Mingkai Hu 
> Signed-off-by: Wenbin Song 
> Signed-off-by: Hou Zhiqiang 

Three signed offs for a simple Kconfig change? And the person doing
the patch has no signed off?? That looks wrong. Maybe the above signed
offs should be acked by?

> ---
> V5: V4 V3 V2
>  - No change.
> 
>  drivers/i2c/busses/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 08b8617..14147ec 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -582,10 +582,10 @@ config I2C_IMG
>  
>  config I2C_IMX
>   tristate "IMX I2C interface"
> - depends on ARCH_MXC
> + depends on ARCH_MXC || ARCH_LAYERSCAPE
>   help
> Say Y here if you want to use the IIC bus controller on
> -   the Freescale i.MX/MXC processors.
> +   the Freescale i.MX/MXC or Layerscape processors.
>  
> This driver can also be built as a module.  If so, the module
> will be called i2c-imx.
> -- 
> 2.1.0.27.g96db324
> 


signature.asc
Description: Digital signature

Re: [PATCH] i2c: rcar: Remove obsolete platform data support

[Wolfram Sang]

On Wed, Oct 07, 2015 at 03:12:34PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 10/7/2015 11:16 AM, Geert Uytterhoeven wrote:
> 
> >Since commit 4baadb9e05c68962 ("ARM: shmobile: r8a7778: remove obsolete
> >setup code"), Renesas R-Car SoCs are only supported in generic DT-only
> >ARM multi-platform builds.  The driver doesn't need to use platform data
> >anymore, hence remove platform data configuration.
> >
> >Signed-off-by: Geert Uytterhoeven 
> >---
> >Commit 4baadb9e05c68962 is now in arm-soc/for-next.
> >---
> >  drivers/i2c/busses/i2c-rcar.c | 19 +--
> >  include/linux/i2c/i2c-rcar.h  | 10 --
> >  2 files changed, 1 insertion(+), 28 deletions(-)
> >  delete mode 100644 include/linux/i2c/i2c-rcar.h
> >
> >diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
> >index 3e125654bb28..cd38406db074 100644
> >--- a/drivers/i2c/busses/i2c-rcar.c
> >+++ b/drivers/i2c/busses/i2c-rcar.c
> [...]
> >@@ -654,14 +652,8 @@ static int rcar_i2c_probe(struct platform_device *pdev)
> >
> > bus_speed = 10; /* default 100 kHz */
> > ret = of_property_read_u32(dev->of_node, "clock-frequency", _speed);
> 
>The result can be ignored now.

Yup, my code checkers found this, too ;)

Fixed it here.

> 
> >-if (ret < 0 && pdata && pdata->bus_speed)
> >-bus_speed = pdata->bus_speed;
> >
> >-if (pdev->dev.of_node)
> >-priv->devtype = (long)of_match_device(rcar_i2c_dt_ids,
> >-  dev)->data;
> >-else
> >-priv->devtype = platform_get_device_id(pdev)->driver_data;
> >+priv->devtype = (long)of_match_device(rcar_i2c_dt_ids, dev)->data;

I changed this to the enum type of devtype

Other than that:

Applied to for-next, thanks!

> >
> > ret = rcar_i2c_clock_calculate(priv, bus_speed, dev);
> > if (ret < 0)
> [...]
> 
> MBR, Sergei
> 


signature.asc
Description: Digital signature

Re: [RESEND PATCH 0/4] i2c: Fix module autoload for OF platform drivers

[Wolfram Sang]

On Tue, Oct 20, 2015 at 03:16:26PM +0100, Luis de Bethencourt wrote:
> Hello,
> 
> This is a resend of this patch series. It was posted on September 17. [0]
> 
> These patches add the missing MODULE_DEVICE_TABLE() for OF to export
> the information so modules have the correct aliases built-in and
> autoloading works correctly.
> 
> A longer explanation by Javier Canillas can be found here:
> https://lkml.org/lkml/2015/7/30/519
> 
> The 4th patch of the series is Acked-by Linus Walleij.

Applied to for-next, thanks!



signature.asc
Description: Digital signature

Re: [PATCH 0/4] Support multiplexed main SMBus interface on SB800

[Wolfram Sang]

On Tue, Aug 25, 2015 at 01:05:01PM +0200, Christian Fetzer wrote:
> This is an attempt to upstream the patches created by Thomas Brandon and
> Eddi De Pieri to support the multiplexed main SMBus interface on the SB800
> chipset. 
> (https://www.mail-archive.com/linux-i2c@vger.kernel.org/msg06757.html)
> 
> I have mainly rebased the latest patch version and tested the driver on a
> HP ProLiant MicroServer G7 N54L (where this patch allows to access sensor data
> from a w83795adg).
> 
> The patched driver is running stable on the machine, given that ic2_piix4 is
> loaded before jc42 and w83795. If jc42 is loaded before i2c_piix4 calling
> sensors triggers some errors:
> ERROR: Can't get value of subfeature temp1_min_alarm: Can't read
> 
> While the kernel log shows:
> i2c i2c-1: Transaction (pre): CNT=0c, CMD=05, ADD=31, DAT0=03, DAT1=c0
> i2c i2c-1: Error: no response!
> i2c i2c-1: Transaction (post): CNT=0c, CMD=05, ADD=31, DAT0=ff, DAT1=ff
> Unfortunately I don't know how to tackle this specific issue.
> 
> Please review and let me know required changes in order to get this upstream
> finally.
> 
> Eddi, Thomas, it would be great if you could verify the changes on your
> machines.

Yes, additional tests are always good for a patch series

Asking the Intel guys for help, I have not much expierence with x86
platforms... Mika, Jarkko, Andy any chance to help?

> 
> Regards,
> Christian
> 
> Christian Fetzer (4):
>   i2c-piix4: Optionally release smba in piix4_adap_remove
>   i2c-piix4: Convert piix4_main_adapter to array
>   i2c-piix4: Add support for multiplexed main adapter in SB800
>   i2c-piix4: Add adapter port name support for SB800 chipset
> 
>  drivers/i2c/busses/i2c-piix4.c | 151 
> -
>  1 file changed, 134 insertions(+), 17 deletions(-)
> 
> -- 
> 1.9.1
> 
> --
> 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


signature.asc
Description: Digital signature

Re: [PATCH v2] dts: keystone: Use new "ti,keystone-i2c" compatible

[Grygorii Strashko]

On 10/20/2015 06:06 PM, Wolfram Sang wrote:

On Mon, Sep 14, 2015 at 11:07:02AM +0200, Alexander Sverdlin wrote:

Now as "i2c-davinci" driver has special handling for Keystone it's time to 
switch
the device tree to use new "compatible" property. Old one is left for backwards-
compatibility.

Signed-off-by: Alexander Sverdlin 


Shall I take this one or shall it go via the davinci tree?



To: Sekhar

--
regards,
-grygorii
--
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: mv64xxx: really allow I2C offloading

[Hezi Shahmoon]

Hi.

It is:
Hezi Shahmoon

Email:
h...@marvell.com

I will fix this for future commits.

Thanks,
Hezi.

-Original Message-
From: Wolfram Sang [mailto:w...@the-dreams.de] 
Sent: Tuesday, October 20, 2015 7:22 PM
To: Thomas Petazzoni
Cc: linux-i2c@vger.kernel.org; Tawfik Bayouk; Nadav Haklai; Lior Amsalem; Jason 
Cooper; Andrew Lunn; Sebastian Hesselbarth; Gregory Clement; Marcin Wojtas; 
Hezi Shahmoon; sta...@vger.kernel.org
Subject: Re: [PATCH] i2c: mv64xxx: really allow I2C offloading

On Tue, Oct 20, 2015 at 04:32:24PM +0200, Thomas Petazzoni wrote:
> From: Hezi 

Is "Hezi" the full name?

> 
> Commit 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix 
> several problems") completely reworked the offload support, but 
> stupidly left a debugging-related "return false" at the beginning of 
> the mv64xxx_i2c_can_offload() function. This has the unfortunate 
> consequence that offloading is in fact never used, which wasn't really 
> the intention.
> 
> This commit fixes that problem by removing the stupid "return false".
> 
> Fixes: 00d8689b85a7 ("i2c: mv64xxx: rework offload support to fix 
> several problems")
> Cc: 
> Signed-off-by: Hezi 
> [Thomas: reworked commit log and title.]
> Signed-off-by: Thomas Petazzoni 
> ---
> Note: the original fix is from Hezi, but I rewrote the commit log, 
> which is why I authorized myself to treat my own work as being 
> "stupid". Which it really was.

:)

> ---
>  drivers/i2c/busses/i2c-mv64xxx.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-mv64xxx.c 
> b/drivers/i2c/busses/i2c-mv64xxx.c
> index 30059c1..5801227 100644
> --- a/drivers/i2c/busses/i2c-mv64xxx.c
> +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> @@ -669,8 +669,6 @@ mv64xxx_i2c_can_offload(struct mv64xxx_i2c_data *drv_data)
>   struct i2c_msg *msgs = drv_data->msgs;
>   int num = drv_data->num_msgs;
>  
> - return false;
> -
>   if (!drv_data->offload_enabled)
>   return false;
>  
> --
> 2.6.2
> 
--
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: [linux-sunxi] [PATCH] i2c: mv64xxx: The n clockdiv factor is 0 based on sunxi SoCs

[Olliver Schinagl]

I shamefully admit I have not. My plate is very full at the moment, but 
I will make room for this upcoming weekend as I have a few other patches 
to test aswell. Sorry for the delay!


On 20-10-15 18:58, Wolfram Sang wrote:

WIth Hans having figured it out and fixing it, I'll absolutly will take a
nother look and check with a scope if it all works out now.

Have you done this already? /me is always looking for Tested-by: tags :)



--
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 v3 1/1] i2c: add ACPI support for I2C mux ports

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 10:49:59 AM Dustin Byford wrote:
> Hi Mika,
> 
> On Tue Oct 20 15:51, Mika Westerberg wrote:
> > On Mon, Oct 19, 2015 at 03:29:00PM -0700, Dustin Byford wrote:
> > > Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
> > > device property compatible string match) enumerating I2C client devices
> > > connected through a I2C mux device requires a little extra work.
> > > 
> > > This change implements a method for describing an I2C device hierarchy 
> > > that
> > > includes mux devices by using an ACPI Device() for each mux channel along
> > > with an _ADR to set the channel number for the device.  See
> > > Documentation/acpi/i2c-muxes.txt for a simple example.
> > > 
> > > Signed-off-by: Dustin Byford 
> > 
> > In general this looks good to me.
> > 
> > > ---
> > >  Documentation/acpi/i2c-muxes.txt | 58 
> > > 
> > >  drivers/i2c/i2c-core.c   | 15 +--
> > >  drivers/i2c/i2c-mux.c|  8 ++
> > >  include/linux/acpi.h |  6 +
> > >  4 files changed, 85 insertions(+), 2 deletions(-)
> > >  create mode 100644 Documentation/acpi/i2c-muxes.txt
> > > 
> > 
> > [...]
> > 
> > > + /*
> > > +  * By default, associate I2C adapters with their parent device's ACPI
> > > +  * node.
> > > +  */
> > > + if (!has_acpi_companion(dev)) {
> > > + struct acpi_device *adev = ACPI_COMPANION(dev->parent);
> > > +
> > > + if (adev)
> > > + ACPI_COMPANION_SET(dev, adev);
> > 
> > Instead of always doing this in the I2C core, maybe we can make it
> > dependent on the host controller driver. For example the I2C designware
> > driver already did this for both DT and ACPI:
> 
> I considered it, but I thought a default that fairly closely matches the
> old behavior was more convenient.
> 
> On the other hand, leaving it up to the controllers makes it all very
> explicit and perhaps simpler to reason about.
> 
> 
> I could be convinced either way.  But, if we move it to the controller
> drivers, which ones need the change?
> 
> grep -i acpi drivers/i2c/busses/i2c*
> 
> shows 18 drivers that might care.
> 
> > adap->dev.parent = >dev;
> > adap->dev.of_node = pdev->dev.of_node;
> > ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
> 
> Interesting, this code isn't in my tree.  I wonder why it was added,
> what code looks at the acpi companion on the i2c dev?  Before my change
> it was supposed to be NULL, and it is NULL on every other controller.

As I said, IMO it should be NULL for i2c devices (power management is the
main reason here).

Thanks,
Rafael

--
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 v3 1/1] i2c: add ACPI support for I2C mux ports

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 03:51:11 PM Mika Westerberg wrote:
> On Mon, Oct 19, 2015 at 03:29:00PM -0700, Dustin Byford wrote:
> > Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
> > device property compatible string match) enumerating I2C client devices
> > connected through a I2C mux device requires a little extra work.
> > 
> > This change implements a method for describing an I2C device hierarchy that
> > includes mux devices by using an ACPI Device() for each mux channel along
> > with an _ADR to set the channel number for the device.  See
> > Documentation/acpi/i2c-muxes.txt for a simple example.
> > 
> > Signed-off-by: Dustin Byford 
> 
> In general this looks good to me.
> 
> > ---
> >  Documentation/acpi/i2c-muxes.txt | 58 
> > 
> >  drivers/i2c/i2c-core.c   | 15 +--
> >  drivers/i2c/i2c-mux.c|  8 ++
> >  include/linux/acpi.h |  6 +
> >  4 files changed, 85 insertions(+), 2 deletions(-)
> >  create mode 100644 Documentation/acpi/i2c-muxes.txt
> > 
> 
> [...]
> 
> > +   /*
> > +* By default, associate I2C adapters with their parent device's ACPI
> > +* node.
> > +*/
> > +   if (!has_acpi_companion(dev)) {
> > +   struct acpi_device *adev = ACPI_COMPANION(dev->parent);
> > +
> > +   if (adev)
> > +   ACPI_COMPANION_SET(dev, adev);
> 
> Instead of always doing this in the I2C core, maybe we can make it
> dependent on the host controller driver. For example the I2C designware
> driver already did this for both DT and ACPI:
> 
>   adap->dev.parent = >dev;
>   adap->dev.of_node = pdev->dev.of_node;
>   ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
> 
> Also I would like to ask what Rafael thinks about this since he authored
> b34bb1ee71158d5b ("ACPI / I2C: Use parent's ACPI_HANDLE() in
> acpi_i2c_register_devices()").
> 
> I don't see a problem multiple Linux devices sharing a single ACPI
> companion device like in this patch but I may be forgetting something ;-)

Well, we already have that in the MFD case, but in principle it may be
problematic for things like power management (say you want to put a
child device into D3, so you use _PS3 on its ACPI companion and then
the parent is powere down instead).

At least, devices in that setup should not be attached to the ACPI PM
domain.

Thanks,
Rafael

--
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 v2] i2c: enable i2c device to suspend/resume asynchronously

[Wolfram Sang]

On Thu, Sep 24, 2015 at 02:26:23PM +0800, Fu, Zhonghui wrote:
> Now, PM core supports asynchronous suspend/resume mode for devices
> during system suspend/resume, and the power state transition of one
> device may be completed in separate kernel thread. PM core ensures
> all power state transition timing dependency between devices. This
> patch enables i2c device to suspend/resume asynchronously. This will
> take advantage of multicore and improve system suspend/resume speed.
> 
> Signed-off-by: Zhonghui Fu 

Does it always work when say a PMIC or clock controller is connected to
the I2C bus?



signature.asc
Description: Digital signature

Re: [PATCH 1/2] i2c: designware: register clkdev during acpi device configuration

[Ken Xue]

On Tue, 2015-10-20 at 14:17 +0300, Mika Westerberg wrote:
> On Tue, Oct 20, 2015 at 02:38:01PM +0800, Ken Xue wrote:
> > DW I2C driver tries to register a clk from id->driver_data as an
> > alternative way besides intel lpss. But code doesn't register the
> > clk to clkdev. So, devm_clk_get will fail during probe.
> > 
> > The patch can fix this issue.
> 
> Since you now have drivers/acpi/acpi_apd.c for AMD ACPI stuff, can you
> create the clock there just like we do for Intel stuff?
Sure. APD already creates the clock for AMD0010 as you expected. And the
next patch([PATCH 2/2] i2c: designware: remove freq definition for
"AMD0010" in acpi_device_id) is dropping the old way for getting freq.

--
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: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki  wrote:
> > On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki  
> >> wrote:
> >> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> >> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse  
> >> >> wrote:
> >> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> >> >> > But the point I'm making is that we are working towards *fixing* 
> >> >> >> > that,
> >> >> >> > and *not* using DT-specific code in places where we should be 
> >> >> >> > using the
> >> >> >> > generic APIs.
> >> >> >>
> >> >> >> What is the plan for fixing things here?  It's not obvious (at least 
> >> >> >> to
> >> >> >> me) that we don't want to have the subsystems having knowledge of how
> >> >> >> they are bound to a specific firmware which is what you seem to imply
> >> >> >> here.
> >> >> >
> >> >> > I don't know that there *is* a coherent plan here to address it all.
> >> >> >
> >> >> > Certainly, we *will* need subsystems to have firmware-specific
> >> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to
> >> >> > describe GPIO, and properties which reference GPIO pins are intended 
> >> >> > to
> >> >> > work through that — while in DT, properties which reference GPIO pins
> >> >> > will have different contents. They'll be compatible at the driver
> >> >> > level, in the sense that there's a call to get a given GPIO given the
> >> >> > property name, but the subsystems *will* be doing different things
> >> >> > behind the scenes.
> >> >> >
> >> >> > My plan, such as it is, is to go through the leaf-node drivers which
> >> >> > almost definitely *should* be firmware-agnostic, and convert those. 
> >> >> > And
> >> >> > then take stock of what we have left, and work out what, if anything,
> >> >> > still needs to be done.
> >> >>
> >> >> Many cases are already agnostic in the drivers in terms of the *_get()
> >> >> functions. Some are DT specific, but probably because those subsystems
> >> >> are new and DT only. In any case, I don't think these 1 line changes
> >> >> do anything to make doing conversions here harder.
> >> >>
> >> >> >> It seems like we're going to have to refactor these bits of code when
> >> >> >> they get generalised anyway so I'm not sure that the additional cost
> >> >> >> here is that big.
> >> >> >
> >> >> > That's an acceptable answer — "we're adding legacy code here but we
> >> >> > know it's going to be refactored anyway". If that's true, all it takes
> >> >> > is a note in the commit comment to that effect. That's different from
> >> >> > having not thought about it :)
> >> >>
> >> >> Considering at one point we did create a fwnode based API, we did
> >> >> think about it. Plus there was little input from ACPI folks as to
> >> >> whether the change was even useful for ACPI case.
> >> >
> >> > Well, sorry, but who was asking whom, specifically?
> >>
> >> You and linux-acpi have been copied on v2 and later of the entire
> >> series I think.
> >
> > Yes, but it wasn't like a direct request, say "We need your input, so can 
> > you
> > please have a look and BTW we want this in 4.4, so please do it ASAP".  In
> > which case I'd prioritize that before other things I needed to take care of.
> 
> Fair enough. Can you please review and comment on v7 of the series? We
> can discuss at KS as well.

I'll do that.

I'm in the middle of travel right now and speaking at a conference tomorrow,
so I may not be able to get to that for a couple of days, but will do my best
to do it as soon as I possibly can.

> >> > The underlying problem is present in ACPI too and we don't really have a 
> >> > good
> >> > solution for it.  We might benefit from a common one if it existed.
> >>
> >> The problem for DT is we don't generically know what are the
> >> dependencies at a core level. We could know some or most dependencies
> >> if phandles (links to other nodes) were typed, but they are not. If
> >> the core had this information, we could simply control the device
> >> creation to order probing. Instead, this information is encoded into
> >> the bindings and binding parsing resides in the subsystems. That
> >> parsing happens during probe of the client side and is done by the
> >> subsystems (for common bindings). Since we already do the parsing at
> >> this point, it is a convenient place to trigger the probe of the
> >> dependency. Is ACPI going to be similar in this regard?
> >
> > It is similar in some ways.  For example, if a device's functionality 
> > depends
> > on an I2C resource (connection), the core doesn't know that at the device
> > creation time at least in some cases.  Same for GPIO, SPI, DMA engines etc.
> 
> So you will need to create devices, defer their probing and then probe
> on demand as well unless you have other ideas how 

Re: [GIT PULL] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, October 20, 2015 08:35:28 PM Mark Brown wrote:
> 
> --7fVr/IRGAG9sAW4J
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> > On Tue, 20 Oct 2015, Tomeu Vizoso wrote:
> 
> > > This iteration of the series would make this quite easy, as
> > > dependencies are calculated before probes are attempted:
> 
> > > https://lkml.org/lkml/2015/6/17/311
> 
> > But what Rafael is proposing is quite general; it would apply to _all_
> > dependencies as opposed to just those present in DT drivers or those=20
> > affecting platform_devices.
> 
> We'll still need most of the DT bits that are there at the minute (the
> ones strewn around the subsystems) AFAICT since it's at the point where
> we parse the DT and work out what the dependencies are which we probably
> want to do prior to getting the drivers up and will be different for
> ACPI.  I think the level of DT dependency here looks a lot larger than
> it actually is due to the fact that a lot of what's being modified is DT
> parsing code.

Right, something will have to register the dependency, or a "link" between
devices, with the core once we find out that the dependency is there.

Thanks,
Rafael

--
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

[PATCH 7/9] MIPS: BMIPS: brcmstb: add I2C node for bcm7358

[Jaedon Shin]

Add I2C device nodes to BMIPS based BCM7358 platform.

Signed-off-by: Jaedon Shin 
---
 arch/mips/boot/dts/brcm/bcm7358.dtsi | 62 ++--
 arch/mips/boot/dts/brcm/bcm97358svmb.dts | 16 +
 2 files changed, 76 insertions(+), 2 deletions(-)

diff --git a/arch/mips/boot/dts/brcm/bcm7358.dtsi 
b/arch/mips/boot/dts/brcm/bcm7358.dtsi
index 277a90adc1a7..8e2501694d03 100644
--- a/arch/mips/boot/dts/brcm/bcm7358.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7358.dtsi
@@ -81,14 +81,32 @@
compatible = "brcm,bcm7120-l2-intc";
reg = <0x406600 0x8>;
 
-   brcm,int-map-mask = <0x44>;
+   brcm,int-map-mask = <0x44>, <0x700>;
brcm,int-fwd-mask = <0x7>;
 
interrupt-controller;
#interrupt-cells = <1>;
 
interrupt-parent = <_intc>;
-   interrupts = <56>;
+   interrupts = <56>, <54>;
+   interrupt-names = "upg_main", "upg_bsc";
+   };
+
+   upg_aon_irq0_intc: upg_aon_irq0_intc@408b80 {
+   compatible = "brcm,bcm7120-l2-intc";
+   reg = <0x408b80 0x8>;
+
+   brcm,int-map-mask = <0x40>, <0x800>, <0x10>;
+   brcm,int-fwd-mask = <0>;
+   brcm,irq-can-wake;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   interrupt-parent = <_intc>;
+   interrupts = <57>, <55>, <59>;
+   interrupt-names = "upg_main_aon", "upg_bsc_aon",
+ "upg_spi";
};
 
sun_top_ctrl: syscon@404000 {
@@ -138,6 +156,46 @@
status = "disabled";
};
 
+   bsca: i2c@406200 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_irq0_intc>;
+ reg = <0x406200 0x58>;
+ interrupts = <24>;
+ interrupt-names = "upg_bsca";
+ status = "disabled";
+   };
+
+   bscb: i2c@406280 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_irq0_intc>;
+ reg = <0x406280 0x58>;
+ interrupts = <25>;
+ interrupt-names = "upg_bscb";
+ status = "disabled";
+   };
+
+   bscc: i2c@406300 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_irq0_intc>;
+ reg = <0x406300 0x58>;
+ interrupts = <26>;
+ interrupt-names = "upg_bscc";
+ status = "disabled";
+   };
+
+   bscd: i2c@408980 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_aon_irq0_intc>;
+ reg = <0x408980 0x58>;
+ interrupts = <27>;
+ interrupt-names = "upg_bscd";
+ status = "disabled";
+   };
+
enet0: ethernet@43 {
phy-mode = "internal";
phy-handle = <>;
diff --git a/arch/mips/boot/dts/brcm/bcm97358svmb.dts 
b/arch/mips/boot/dts/brcm/bcm97358svmb.dts
index a8dc01e30313..02ce6b429dc4 100644
--- a/arch/mips/boot/dts/brcm/bcm97358svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97358svmb.dts
@@ -29,6 +29,22 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.6.1

--
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

[PATCH 8/9] MIPS: BMIPS: brcmstb: add I2C node for bcm7360

[Jaedon Shin]

Add I2C device nodes to BMIPS based BCM7360 platform.

Signed-off-by: Jaedon Shin 
---
 arch/mips/boot/dts/brcm/bcm7360.dtsi | 62 ++--
 arch/mips/boot/dts/brcm/bcm97360svmb.dts | 16 +
 2 files changed, 76 insertions(+), 2 deletions(-)

diff --git a/arch/mips/boot/dts/brcm/bcm7360.dtsi 
b/arch/mips/boot/dts/brcm/bcm7360.dtsi
index 9e1e571ba346..7e5f76040fb8 100644
--- a/arch/mips/boot/dts/brcm/bcm7360.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7360.dtsi
@@ -81,14 +81,32 @@
compatible = "brcm,bcm7120-l2-intc";
reg = <0x406600 0x8>;
 
-   brcm,int-map-mask = <0x44>;
+   brcm,int-map-mask = <0x44>, <0x700>;
brcm,int-fwd-mask = <0x7>;
 
interrupt-controller;
#interrupt-cells = <1>;
 
interrupt-parent = <_intc>;
-   interrupts = <56>;
+   interrupts = <56>, <54>;
+   interrupt-names = "upg_main", "upg_bsc";
+   };
+
+   upg_aon_irq0_intc: upg_aon_irq0_intc@408b80 {
+   compatible = "brcm,bcm7120-l2-intc";
+   reg = <0x408b80 0x8>;
+
+   brcm,int-map-mask = <0x40>, <0x800>, <0x10>;
+   brcm,int-fwd-mask = <0>;
+   brcm,irq-can-wake;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   interrupt-parent = <_intc>;
+   interrupts = <57>, <55>, <59>;
+   interrupt-names = "upg_main_aon", "upg_bsc_aon",
+ "upg_spi";
};
 
sun_top_ctrl: syscon@404000 {
@@ -138,6 +156,46 @@
status = "disabled";
};
 
+   bsca: i2c@406200 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_irq0_intc>;
+ reg = <0x406200 0x58>;
+ interrupts = <24>;
+ interrupt-names = "upg_bsca";
+ status = "disabled";
+   };
+
+   bscb: i2c@406280 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_irq0_intc>;
+ reg = <0x406280 0x58>;
+ interrupts = <25>;
+ interrupt-names = "upg_bscb";
+ status = "disabled";
+   };
+
+   bscc: i2c@406300 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_irq0_intc>;
+ reg = <0x406300 0x58>;
+ interrupts = <26>;
+ interrupt-names = "upg_bscc";
+ status = "disabled";
+   };
+
+   bscd: i2c@408980 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_aon_irq0_intc>;
+ reg = <0x408980 0x58>;
+ interrupts = <27>;
+ interrupt-names = "upg_bscd";
+ status = "disabled";
+   };
+
enet0: ethernet@43 {
phy-mode = "internal";
phy-handle = <>;
diff --git a/arch/mips/boot/dts/brcm/bcm97360svmb.dts 
b/arch/mips/boot/dts/brcm/bcm97360svmb.dts
index eee8b0e32681..d48462e091f1 100644
--- a/arch/mips/boot/dts/brcm/bcm97360svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97360svmb.dts
@@ -29,6 +29,22 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.6.1

--
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

[PATCH 0/9] i2c: brcmstb: add support for BMIPS_GENERIC

[Jaedon Shin]

Hi all,

This patch series adds support for BMIPS_GENERIC, and fixes running conditions.

Thanks.

Jaedon Shin (9):
  i2c: brcmstb: make the driver buildable on BMIPS_GENERIC
  i2c: brcmstb: fix typo in i2c-brcmstb
  i2c: brcmstb: add missing parenthesis
  i2c: brcmstb: enable ACK condition
  i2c: brcmstb: fix start and stop conditions
  MIPS: BMIPS: brcmstb: add I2C node for bcm7346
  MIPS: BMIPS: brcmstb: add I2C node for bcm7358
  MIPS: BMIPS: brcmstb: add I2C node for bcm7360
  MIPS: BMIPS: brcmstb: add I2C node for bcm7362

 arch/mips/boot/dts/brcm/bcm7346.dtsi  | 72 ++-
 arch/mips/boot/dts/brcm/bcm7358.dtsi  | 62 +-
 arch/mips/boot/dts/brcm/bcm7360.dtsi  | 62 +-
 arch/mips/boot/dts/brcm/bcm7362.dtsi  | 52 +-
 arch/mips/boot/dts/brcm/bcm97346dbsmb.dts | 20 +
 arch/mips/boot/dts/brcm/bcm97358svmb.dts  | 16 +++
 arch/mips/boot/dts/brcm/bcm97360svmb.dts  | 16 +++
 arch/mips/boot/dts/brcm/bcm97362svmb.dts  | 12 ++
 drivers/i2c/busses/Kconfig|  2 +-
 drivers/i2c/busses/i2c-brcmstb.c  | 11 +++--
 10 files changed, 310 insertions(+), 15 deletions(-)

-- 
2.6.1

--
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

[PATCH 5/9] i2c: brcmstb: fix start and stop conditions

[Jaedon Shin]

Fixes conditions for RESTART, NOSTART and NOSTOP. The masks of start and
stop is already in brcmstb_set_i2c_start_stop(). Therefore, the caller
does not need a mask value.

Signed-off-by: Jaedon Shin 
---
 drivers/i2c/busses/i2c-brcmstb.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-brcmstb.c b/drivers/i2c/busses/i2c-brcmstb.c
index 53eb8b0c9bad..dcd1209f843f 100644
--- a/drivers/i2c/busses/i2c-brcmstb.c
+++ b/drivers/i2c/busses/i2c-brcmstb.c
@@ -464,7 +464,7 @@ static int brcmstb_i2c_xfer(struct i2c_adapter *adapter,
pmsg->buf ? pmsg->buf[0] : '0', pmsg->len);
 
if (i < (num - 1) && (msgs[i + 1].flags & I2C_M_NOSTART))
-   brcmstb_set_i2c_start_stop(dev, ~(COND_START_STOP));
+   brcmstb_set_i2c_start_stop(dev, 0);
else
brcmstb_set_i2c_start_stop(dev,
   COND_RESTART | COND_NOSTOP);
@@ -485,8 +485,7 @@ static int brcmstb_i2c_xfer(struct i2c_adapter *adapter,
bytes_to_xfer = min(len, N_DATA_BYTES);
 
if (len <= N_DATA_BYTES && i == (num - 1))
-   brcmstb_set_i2c_start_stop(dev,
-  ~(COND_START_STOP));
+   brcmstb_set_i2c_start_stop(dev, 0);
 
rc = brcmstb_i2c_xfer_bsc_data(dev, tmp_buf,
   bytes_to_xfer, pmsg);
-- 
2.6.1

--
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

[PATCH 9/9] MIPS: BMIPS: brcmstb: add I2C node for bcm7362

[Jaedon Shin]

Add I2C device nodes to BMIPS based BCM7362 platform.

Signed-off-by: Jaedon Shin 
---
 arch/mips/boot/dts/brcm/bcm7362.dtsi | 52 ++--
 arch/mips/boot/dts/brcm/bcm97362svmb.dts | 12 
 2 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/arch/mips/boot/dts/brcm/bcm7362.dtsi 
b/arch/mips/boot/dts/brcm/bcm7362.dtsi
index 6e65db86fc61..5f817be2553c 100644
--- a/arch/mips/boot/dts/brcm/bcm7362.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7362.dtsi
@@ -87,14 +87,32 @@
compatible = "brcm,bcm7120-l2-intc";
reg = <0x406600 0x8>;
 
-   brcm,int-map-mask = <0x44>;
+   brcm,int-map-mask = <0x44>, <0x700>;
brcm,int-fwd-mask = <0x7>;
 
interrupt-controller;
#interrupt-cells = <1>;
 
interrupt-parent = <_intc>;
-   interrupts = <56>;
+   interrupts = <56>, <54>;
+   interrupt-names = "upg_main", "upg_bsc";
+   };
+
+   upg_aon_irq0_intc: upg_aon_irq0_intc@408b80 {
+   compatible = "brcm,bcm7120-l2-intc";
+   reg = <0x408b80 0x8>;
+
+   brcm,int-map-mask = <0x40>, <0x800>, <0x10>;
+   brcm,int-fwd-mask = <0>;
+   brcm,irq-can-wake;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   interrupt-parent = <_intc>;
+   interrupts = <57>, <55>, <59>;
+   interrupt-names = "upg_main_aon", "upg_bsc_aon",
+ "upg_spi";
};
 
sun_top_ctrl: syscon@404000 {
@@ -144,6 +162,36 @@
status = "disabled";
};
 
+   bsca: i2c@406200 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_irq0_intc>;
+ reg = <0x406200 0x58>;
+ interrupts = <24>;
+ interrupt-names = "upg_bsca";
+ status = "disabled";
+   };
+
+   bscb: i2c@406280 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_irq0_intc>;
+ reg = <0x406280 0x58>;
+ interrupts = <25>;
+ interrupt-names = "upg_bscb";
+ status = "disabled";
+   };
+
+   bscd: i2c@408980 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_aon_irq0_intc>;
+ reg = <0x408980 0x58>;
+ interrupts = <27>;
+ interrupt-names = "upg_bscd";
+ status = "disabled";
+   };
+
enet0: ethernet@43 {
phy-mode = "internal";
phy-handle = <>;
diff --git a/arch/mips/boot/dts/brcm/bcm97362svmb.dts 
b/arch/mips/boot/dts/brcm/bcm97362svmb.dts
index 739c2ef5663b..9c99bfd1e781 100644
--- a/arch/mips/boot/dts/brcm/bcm97362svmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97362svmb.dts
@@ -29,6 +29,18 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.6.1

--
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

[PATCH 4/9] i2c: brcmstb: enable ACK condition

[Jaedon Shin]

Removes the condition of a message with under 32 bytes in length. The
messages that do not require an ACK are I2C_M_IGNORE_NAK flag.

Signed-off-by: Jaedon Shin 
---
 drivers/i2c/busses/i2c-brcmstb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-brcmstb.c b/drivers/i2c/busses/i2c-brcmstb.c
index 2d7d155029dc..53eb8b0c9bad 100644
--- a/drivers/i2c/busses/i2c-brcmstb.c
+++ b/drivers/i2c/busses/i2c-brcmstb.c
@@ -330,7 +330,7 @@ static int brcmstb_i2c_xfer_bsc_data(struct brcmstb_i2c_dev 
*dev,
int no_ack = pmsg->flags & I2C_M_IGNORE_NAK;
 
/* see if the transaction needs to check NACK conditions */
-   if (no_ack || len <= N_DATA_BYTES) {
+   if (no_ack) {
cmd = (pmsg->flags & I2C_M_RD) ? CMD_RD_NOACK
: CMD_WR_NOACK;
pi2creg->ctlhi_reg |= BSC_CTLHI_REG_IGNORE_ACK_MASK;
-- 
2.6.1

--
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

[PATCH 6/9] MIPS: BMIPS: brcmstb: add I2C node for bcm7346

[Jaedon Shin]

Add I2C device nodes to BMIPS based BCM7346 platform.

Signed-off-by: Jaedon Shin 
---
 arch/mips/boot/dts/brcm/bcm7346.dtsi  | 72 ++-
 arch/mips/boot/dts/brcm/bcm97346dbsmb.dts | 20 +
 2 files changed, 90 insertions(+), 2 deletions(-)

diff --git a/arch/mips/boot/dts/brcm/bcm7346.dtsi 
b/arch/mips/boot/dts/brcm/bcm7346.dtsi
index d817bb46b934..0a1927099075 100644
--- a/arch/mips/boot/dts/brcm/bcm7346.dtsi
+++ b/arch/mips/boot/dts/brcm/bcm7346.dtsi
@@ -87,14 +87,32 @@
compatible = "brcm,bcm7120-l2-intc";
reg = <0x406780 0x8>;
 
-   brcm,int-map-mask = <0x44>;
+   brcm,int-map-mask = <0x44>, <0xf00>;
brcm,int-fwd-mask = <0x7>;
 
interrupt-controller;
#interrupt-cells = <1>;
 
interrupt-parent = <_intc>;
-   interrupts = <59>;
+   interrupts = <59>, <57>;
+   interrupt-names = "upg_main", "upg_bsc";
+   };
+
+   upg_aon_irq0_intc: upg_aon_irq0_intc@408b80 {
+   compatible = "brcm,bcm7120-l2-intc";
+   reg = <0x408b80 0x8>;
+
+   brcm,int-map-mask = <0x40>, <0x800>, <0x10>;
+   brcm,int-fwd-mask = <0>;
+   brcm,irq-can-wake;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   interrupt-parent = <_intc>;
+   interrupts = <60>, <58>, <62>;
+   interrupt-names = "upg_main_aon", "upg_bsc_aon",
+ "upg_spi";
};
 
sun_top_ctrl: syscon@404000 {
@@ -144,6 +162,56 @@
status = "disabled";
};
 
+   bsca: i2c@406200 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_irq0_intc>;
+ reg = <0x406200 0x58>;
+ interrupts = <24>;
+ interrupt-names = "upg_bsca";
+ status = "disabled";
+   };
+
+   bscb: i2c@406280 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_irq0_intc>;
+ reg = <0x406280 0x58>;
+ interrupts = <25>;
+ interrupt-names = "upg_bscb";
+ status = "disabled";
+   };
+
+   bscc: i2c@406300 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_irq0_intc>;
+ reg = <0x406300 0x58>;
+ interrupts = <26>;
+ interrupt-names = "upg_bscc";
+ status = "disabled";
+   };
+
+   bscd: i2c@406380 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_irq0_intc>;
+ reg = <0x406380 0x58>;
+ interrupts = <27>;
+ interrupt-names = "upg_bscd";
+ status = "disabled";
+   };
+
+   bsce: i2c@408980 {
+ clock-frequency = <39>;
+ compatible = "brcm,brcmstb-i2c";
+ interrupt-parent = <_aon_irq0_intc>;
+ reg = <0x408980 0x58>;
+ interrupts = <27>;
+ interrupt-names = "upg_bsce";
+ status = "disabled";
+   };
+
enet0: ethernet@43 {
phy-mode = "internal";
phy-handle = <>;
diff --git a/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts 
b/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
index 3fe0445b9d37..a5b6365afc5f 100644
--- a/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
+++ b/arch/mips/boot/dts/brcm/bcm97346dbsmb.dts
@@ -29,6 +29,26 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.6.1

--
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

[PATCH 2/9] i2c: brcmstb: fix typo in i2c-brcmstb

[Jaedon Shin]

Fixes the "definitions" where it is spelled "defintions".

Signed-off-by: Jaedon Shin 
---
 drivers/i2c/busses/i2c-brcmstb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-brcmstb.c b/drivers/i2c/busses/i2c-brcmstb.c
index 8e9637eea512..6b8bbf99880d 100644
--- a/drivers/i2c/busses/i2c-brcmstb.c
+++ b/drivers/i2c/busses/i2c-brcmstb.c
@@ -41,7 +41,7 @@
 #define BSC_CTL_REG_INT_EN_SHIFT   6
 #define BSC_CTL_REG_DIV_CLK_MASK   0x0080
 
-/* BSC_IIC_ENABLE r/w enable and interrupt field defintions */
+/* BSC_IIC_ENABLE r/w enable and interrupt field definitions */
 #define BSC_IIC_EN_RESTART_MASK0x0040
 #define BSC_IIC_EN_NOSTART_MASK0x0020
 #define BSC_IIC_EN_NOSTOP_MASK 0x0010
-- 
2.6.1

--
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

[PATCH 3/9] i2c: brcmstb: add missing parenthesis

[Jaedon Shin]

Add the necessary parenthesis for NOACK condition.

Signed-off-by: Jaedon Shin 
---
 drivers/i2c/busses/i2c-brcmstb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-brcmstb.c b/drivers/i2c/busses/i2c-brcmstb.c
index 6b8bbf99880d..2d7d155029dc 100644
--- a/drivers/i2c/busses/i2c-brcmstb.c
+++ b/drivers/i2c/busses/i2c-brcmstb.c
@@ -305,7 +305,7 @@ static int brcmstb_send_i2c_cmd(struct brcmstb_i2c_dev *dev,
}
 
if ((CMD_RD || CMD_WR) &&
-   bsc_readl(dev, iic_enable) & BSC_IIC_EN_NOACK_MASK) {
+   (bsc_readl(dev, iic_enable) & BSC_IIC_EN_NOACK_MASK)) {
rc = -EREMOTEIO;
dev_dbg(dev->device, "controller received NOACK intr for %s\n",
cmd_string[cmd]);
-- 
2.6.1

--
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

[PATCH 1/9] i2c: brcmstb: make the driver buildable on BMIPS_GENERIC

[Jaedon Shin]

The BCM7xxx ARM and MIPS platforms share a similar hardware block for
I2C.

Signed-off-by: Jaedon Shin 
---
 drivers/i2c/busses/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 08b86178e8fb..fd983c5b36f2 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -394,7 +394,7 @@ config I2C_BCM_KONA
 
 config I2C_BRCMSTB
tristate "BRCM Settop I2C controller"
-   depends on ARCH_BRCMSTB || COMPILE_TEST
+   depends on ARCH_BRCMSTB || BMIPS_GENERIC || COMPILE_TEST
default y
help
  If you say yes to this option, support will be included for the
-- 
2.6.1

--
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: Alternative approach to solve the deferred probe

[Frank Rowand]

On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote:
>> Hi Russell,
>>
>> On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux
>>  wrote:
> What you can do is print those devices which have failed to probe at
> late_initcall() time - possibly augmenting that with reports from
> subsystems showing what resources are not available, but that's only
> a guide, because of the "it might or might not be in a kernel module"
> problem.

 Well, adding those reports would give you a changelog similar to the
 one in this series...
>>>
>>> I'm not sure about that, because what I was thinking of is adding
>>> a flag which would be set at late_initcall() time prior to running
>>> a final round of deferred device probing.
>>
>> Which round is the final round?
>> That's the one which didn't manage to bind any new devices to drivers,
>> which is something you only know _after_ the round has been run.
>>
>> So I think we need one extra round to handle this.
>>
>>> This flag would then be used in a deferred_warn() printk function
>>> which would normally be silent, but when this flag is set, it would
>>> print the reason for the deferral - and this would replace (or be
>>> added) to the subsystems and drivers which return -EPROBE_DEFER.
>>>
>>> That has the effect of hiding all the deferrals up until just before
>>> launching into userspace, which should then acomplish two things -
>>> firstly, getting rid of the rather useless deferred messages up to
>>> that point, and secondly printing the reason why the remaining
>>> deferrals are happening.
>>>
>>> That should be a small number of new lines plus a one-line change
>>> in subsystems and drivers.
>>
>> Apart from the extra round we probably can't get rid of, that sounds OK to 
>> me.
> 
> Something like this.  I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
> be fwnode?)  See the commented out of_warn_deferred() in
> drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
> for resources should make debugging why things are getting deferred easier.
> 
> We could make driver_deferred_probe_report something that can be
> deactivated again after the last deferred probe run, and provide the
> user with a knob that they can turn it back on again.
> 
> I've tried this out on two of my platforms, including forcing
> driver_deferred_probe_report to be enabled, and I get exactly one
> deferred probe, so not a particularly good test.
> 
> The patch won't apply as-is to mainline for all files; it's based on my
> tree which has some 360 additional patches (which seems to be about
> normal for my tree now.)

I like the concept (I have been thinking along similar lines lately).
But I think this might make the console messages more confusing than
they are now.  The problem is that debug, warn, and error messages
come from a somewhat random set of locations at the moment.  Some
come from the driver probe routines and some come from the subsystems
that the probe routines call.  So the patch is suppressing some
messages, but not others.

One thing that seemed pretty obvious from the patches is that the
current probe routines are somewhat inconsistent in terms of messages,
and that there is room for a set of best practices for messaging.  That
is on my long term wish list, but I'm not sure I'll ever chase after
those windmills.

A couple of specific comments below.


> 
>  drivers/base/dd.c   | 29 +
>  drivers/base/power/domain.c |  7 +--
>  drivers/clk/clkdev.c|  9 -
>  drivers/gpio/gpiolib-of.c   |  5 +
>  drivers/gpu/drm/bridge/dw_hdmi.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  2 +-
>  drivers/gpu/drm/imx/imx-ldb.c   |  5 +++--
>  drivers/gpu/drm/msm/dsi/dsi.c   |  2 +-
>  drivers/gpu/drm/msm/msm_drv.c   |  3 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
>  drivers/of/irq.c|  5 -
>  drivers/pci/host/pci-mvebu.c|  1 +
>  drivers/pinctrl/core.c  |  5 +++--
>  drivers/pinctrl/devicetree.c|  4 ++--
>  drivers/regulator/core.c|  5 +++--
>  include/linux/device.h  |  1 +
>  16 files changed, 71 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index be0eb4639128..bb12224f2901 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev)
>   mutex_unlock(_probe_mutex);
>  }
>  
> +static bool driver_deferred_probe_report;
> +
> +/**
> + * dev_warn_deferred() - report why a probe has been deferred
> + */
> +void 

RE: [PATCH V5 1/6] i2c: Add i2c support to Freescale Layerscape platforms

[Hou Zhiqiang]

> -Original Message-
> From: Wolfram Sang [mailto:w...@the-dreams.de]
> Sent: 2015年10月20日 23:53
> To: Hou Zhiqiang-B48286
> Cc: linux-arm-ker...@lists.infradead.org; catalin.mari...@arm.com;
> will.dea...@arm.com; linux-i2c@vger.kernel.org; linux-
> watch...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> c...@vger.kernel.org; mark.rutl...@arm.com; li...@roeck-us.net;
> w...@iguana.be; cor...@lwn.net; mturque...@baylibre.com;
> sb...@codeaurora.org; Hu Mingkai-B21284; Xie Shaohui-B21989; Wood Scott-
> B07421; Sharma Bhupesh-B45370; Song Wenbin-B53747
> Subject: Re: [PATCH V5 1/6] i2c: Add i2c support to Freescale Layerscape
> platforms
> 
> On Mon, Oct 19, 2015 at 07:56:09PM +0800, Zhiqiang Hou wrote:
> > From: Shaohui Xie 
> >
> > Modify the I2C_IMX config to support to Layerscape platforms.
> >
> > Signed-off-by: Mingkai Hu 
> > Signed-off-by: Wenbin Song 
> > Signed-off-by: Hou Zhiqiang 
> 
> Three signed offs for a simple Kconfig change? And the person doing the
> patch has no signed off?? That looks wrong. Maybe the above signed offs
> should be acked by?
> 

Will add the signed-off of the author.

Thanks,
Zhiqiang

Re: [PATCH] i2c: at91: fix write transfers by clearing pending interrupt first

[Ludovic Desroches]

On Mon, Oct 19, 2015 at 12:49:03PM +0200, Peter Rosin wrote:
> On 2015-10-19 10:51, Ludovic Desroches wrote:
> > Hi Peter,
> > 
> > On Fri, Oct 16, 2015 at 11:08:42AM +0200, Peter Rosin wrote:
> >> On 2015-10-16 01:47, Peter Rosin wrote:
> >>> On 2015-10-14 07:43, Ludovic Desroches wrote:
>  On Tue, Oct 13, 2015 at 08:01:34PM +0200, Peter Rosin wrote:
> > On 2015-10-13 18:47, Cyrille Pitchen wrote:
> >> Le 13/10/2015 17:19, Peter Rosin a écrit :
> >>> On 2015-10-13 16:21, Ludovic Desroches wrote:
> > 
> > [...]
> > 
> >>> I have started to get this when I run with this patch:
> >>>
> >>> [   73.31] at91_i2c f0014000.i2c: RXRDY still set!
> >>> [  198.20] at91_i2c f0014000.i2c: RXRDY still set!
> >>> [  509.88] at91_i2c f0014000.i2c: RXRDY still set!
> >>> [  615.75] at91_i2c f0014000.i2c: RXRDY still set!
> >>> [  617.75] at91_i2c f0014000.i2c: RXRDY still set!
> >>> [ 1766.64] at91_i2c f0014000.i2c: RXRDY still set!
> >>> [ 2035.38] at91_i2c f0014000.i2c: RXRDY still set!
> >>> [ 2227.19] at91_i2c f0014000.i2c: RXRDY still set!
> >>> [ 2313.10] at91_i2c f0014000.i2c: RXRDY still set!
> >>>
> >>> My USB serial dongle was hung which was why I didn't notice until just 
> >>> now.
> >>>
> >>> This is probably not when communication with the eeprom though, and 
> >>> certainly not
> >>> writing to it, but perhpaps when polling the temperature (using the jc42 
> >>> driver).
> >>> I'll investigate further in the morning to see if I can pinpoint it.
> >>
> >> Yep, it's the jc42 accesses that triggers this (to the same chip as the
> >> eeprom, but a different block of transistors I suppose).
> >>
> >> Looking at the i2c bus, the accesses normally go like this:
> >>
> >> [0.00] S 0x18 W 0x05 S 0x18 R 0xc1 0xbe NACK P
> >> [0.000521] S 0x18 W 0x04 S 0x18 R 0x00 0x00 NACK P
> >> [0.001024] S 0x18 W 0x03 S 0x18 R 0x00 0x00 NACK P
> >> [0.001524] S 0x18 W 0x02 S 0x18 R 0x00 0x00 NACK P
> >> [0.196991] S 0x18 W 0x05 S 0x18 R 0xc1 0xbe NACK P
> >> [0.197514] S 0x18 W 0x04 S 0x18 R 0x00 0x00 NACK P
> >> [0.198019] S 0x18 W 0x03 S 0x18 R 0x00 0x00 NACK P
> >> [0.198520] S 0x18 W 0x02 S 0x18 R 0x00 0x00 NACK P
> >>
> >> I.e. chunks of four transfers every ~200 ms (I removed the 1Hz rate
> >> limiter in the jc42 driver to get more frequent incidents).
> >>
> >> But when the diagnostic (RXRDY still set!) is output it continues
> >> with this:
> >>
> >> [0.399755] S 0x18 W 0x05 S 0x18 R 0xc1 0xbe NACK P
> >> [0.404998] S 0x18 W 0x04 S 0x18 R 0x00 0x00 NACK P
> >> [0.405508] S 0x18 W 0x03 S 0x18 R 0x00 0x00 NACK P
> >> [0.406008] S 0x18 W 0x02 S 0x18 R 0x00 0x00 NACK P
> >>
> >> Notice the ~5 ms delay (about the time it should take to output
> >> the diagnostic at 115200 baud) after the access to register 0x05
> >> at 0.399755.
> >>
> >> This is the only thing that I can observe on the bus, so it appears
> >> to be harmless.
> >>
> >> It appears that the i2c access at 0.399755 finds the TWI
> >> registers in an odd state, but nothing from the access at
> >> 0.198520 appears to have gone wrong. Is this a race? Anyway,
> >> the diagnostic is pretty frequent and annoying. printk_once?
> > 
> > I'll try to reproduce it on my side. The only issue you have is having
> > the message about RXRDY? I mean no issue with i2c transfers?
> 
> Exactly, the only issue is the message, the bus looks good and transfers
> work as they should AFAICT.
> > It is not the possible bug we had in mind, this bug will prevent the
> > master device to release the i2c bus. It will stop the transfer but
> > without sending a stop on the bus.
> 
> Agreed, this is not about the extra frame caused by the spurious write
> to the THR register. This is something else.
> 
> One suspicion is that the driver gets an unexpected irq from its own
> NACK (the one that it puts out to end the read) and races with the
> expected interrupt at TXCOMP?
>

I have discussed with the designer of this IP. So the NACK flag is only
used for 'real' nack not protocol ones.

Concerning the read issue, it have attached a patch (apply it on top of
Cyrille's patch). Could you have a try? I have reproduced your issue only one
time so it's hard for me to tell if it works well or not.

Regards

Ludovic
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 94c087b..05e3d8e 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -347,8 +347,14 @@ error:
 
 static void at91_twi_read_next_byte(struct at91_twi_dev *dev)
 {
-	if (!dev->buf_len)
+	/*
+	 * If we are in this case, it means there is garbage data in RHR, so
+	 * delete them.
+	 */
+	if (!dev->buf_len) {
+		at91_twi_read(dev, AT91_TWI_RHR);
 		return;
+	}
 
 	/* 8bit read works with and without FIFO */
 	*dev->buf = readb_relaxed(dev->base + AT91_TWI_RHR);
@@ -465,6 +471,8 @@ static irqreturn_t atmel_twi_interrupt(int irq, void *dev_id)
 
 	if (!irqstatus)
 		return IRQ_NONE;
+	if (irqstatus & AT91_TWI_RXRDY)
+