Re: [PATCH v4 4/5] at24: enable ACPI device found on Galileo Gen2

2015-10-23 Thread Ben Gardner
Hi,

On Fri, Oct 23, 2015 at 4:16 AM, Andy Shevchenko
 wrote:
> There is a 24c08 chip connected to i2c bus on Intel Galileo Gen2 board. Enable
> it via ACPI ID INT3499.

I'm looking to do something similar with a 24C02 and would like to
know if there is an ID already defined for that.

Is there a master list of ACPI IDs?

The best I found is here: http://www.uefi.org/PNP_ACPI_Registry
But that doesn't seem to have individual numbers and it indicates that
the "INT" PNP ID is reserved by INTERPHASE CORPORATION.
Intel Corp looks to have "ICO" for the PNP ID and ACPI/INTC/INTL for ACPI IDs.

Thanks,
Ben
--
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


ACPI I2C device-driver matching issue

2015-10-22 Thread Ben Gardner
Hi all,

I have a custom Baytrail board with a M24C02 EEPROM attached to I2C bus 3.
I am using coreboot/SeaBIOS, so I have complete control over the ACPI tables.
I am using Linux 4.2.3.

I have defined a EEPROM device on I2C3 using I2cSerialBus() and it
shows up as expected.

Scope (\_SB.PCI0.I2C3) {
  Device (EEP0) {
Name (_CID, Package() { "24c02" })
Name (_CRS, ResourceTemplate () {
  I2cSerialBus (0x0057, ControllerInitiated, 40,
AddressingMode7Bit, "\\_SB.PCI0.I2C3", 0x00,
ResourceConsumer,,)
})
  }
}

Everything is nearly working, except that acpi_i2c_add_device() is
using the ACPI name to match the driver, which is "24C02:00".
The "at42" driver supports the device with the "24c02" alias.
i2c_match_id() in i2c-core.c uses strcmp() to match the device.
That obviously doesn't match, as "24c02" != "24C02:00".

When I modified acpi_i2c_add_device() to truncate at the colon and
convert it to lower case, it matches and works.


What is the right way to declare a I2C device in ACPI so that it
matches existing drivers?


For reference only, I included the change I made to get it to work below.
(Copy/pasted into gmail, so tabs are lost.)

Thanks,
Ben Gardner

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index c83e4d1..64caddc 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -144,7 +144,13 @@ static acpi_status
acpi_i2c_add_device(acpi_handle handle, u32 level,
return AE_OK;

adev->power.flags.ignore_parent = true;
-   strlcpy(info.type, dev_name(>dev), sizeof(info.type));
+   {
+   const char *dn = dev_name(>dev);
+   int idx;
+   for (idx = 0; idx < sizeof(info.type) - 1 && dn[idx]
&& dn[idx] != ':'; idx++)
+   info.type[idx] = tolower(dn[idx]);
+   }
if (!i2c_new_device(adapter, )) {
adev->power.flags.ignore_parent = false;
dev_err(>dev,
--
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] rtc-isl1208: Use SMBus functions if I2C isn't available

2011-10-26 Thread Ben Gardner
Hi Jonathan,

Thanks for the review.

On Wed, Oct 26, 2011 at 3:40 AM, Jonathan Cameron ji...@cam.ac.uk wrote:
 On 10/26/11 03:30, Ben Gardner wrote:
 The rtc-isl1208 driver currently depends on raw I2C functionality.
 This patch adds a fall-back to SMBus functions so that the driver can be
 used on a SMBus-only platforms, such as i2c-isch.

 Perhaps a summary of how bad things would be if smbus were all that is used?
 Afterall it is emulated on i2c buses if they don't support it directly.

Read and writes to the RTC chip should be a very rare thing, so saving
a few cycles by using the native I2C block read/write seems less
important than being compatible.
Perhaps I should just switch it to using SMBus functions and eliminate
the I2C block ops altogether?

Anyone else have an opinion on this?

 -     ret = i2c_transfer(client-adapter, msgs, 2);
 -     if (ret  0)
 -             ret = 0;
 It's a bit early in the morning, but at least at first glance I think
 this is an i2c_smbus_i2c_read_block_data reimplementation?

Do you mean i2c_smbus_read_i2c_block_data()?
That function is a bit different - it uses i2c_transfer() to emulate
the SMBus block read.
I'm not aware of any SMBus emulation of a I2C block read.

 +     if (i2c_check_functionality(client-adapter, I2C_FUNC_I2C)) {
 +             u8 reg_addr[1] = { reg };
 +             struct i2c_msg msgs[2] = {
 +                     {client-addr, 0, sizeof(reg_addr), reg_addr}
 +                     ,
 Odd spacing.

Sure is. It was that way in the original, but I guess I'll fix it. Or
eliminate it, if I remove I2C ops in the next version.

I'll await further comments and then repost in a day or so.

Thanks,
Ben
--
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] rtc-isl1208: Add support for the ISL1218

2011-10-25 Thread Ben Gardner
The ISL1218 chip is identical to the ISL1208, except that it has 6
additional user-storage registers. This patch does not enable access 
to those additional registers, but only adds the chip name to the list.

Signed-off-by: Ben Gardner gardner@gmail.com
---
 drivers/rtc/rtc-isl1208.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/rtc/rtc-isl1208.c b/drivers/rtc/rtc-isl1208.c
index da8beb8..ea10736 100644
--- a/drivers/rtc/rtc-isl1208.c
+++ b/drivers/rtc/rtc-isl1208.c
@@ -697,6 +697,7 @@ isl1208_remove(struct i2c_client *client)
 
 static const struct i2c_device_id isl1208_id[] = {
{ isl1208, 0 },
+   { isl1218, 0 },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, isl1208_id);
-- 
1.7.7

--
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] rtc-isl1208: Use SMBus functions if I2C isn't available

2011-10-25 Thread Ben Gardner
The rtc-isl1208 driver currently depends on raw I2C functionality.
This patch adds a fall-back to SMBus functions so that the driver can be 
used on a SMBus-only platforms, such as i2c-isch.

Signed-off-by: Ben Gardner gardner@gmail.com
---
 drivers/rtc/rtc-isl1208.c |   68 +++-
 1 files changed, 48 insertions(+), 20 deletions(-)

diff --git a/drivers/rtc/rtc-isl1208.c b/drivers/rtc/rtc-isl1208.c
index ea10736..c553c7b 100644
--- a/drivers/rtc/rtc-isl1208.c
+++ b/drivers/rtc/rtc-isl1208.c
@@ -66,20 +66,35 @@ static int
 isl1208_i2c_read_regs(struct i2c_client *client, u8 reg, u8 buf[],
  unsigned len)
 {
-   u8 reg_addr[1] = { reg };
-   struct i2c_msg msgs[2] = {
-   {client-addr, 0, sizeof(reg_addr), reg_addr}
-   ,
-   {client-addr, I2C_M_RD, len, buf}
-   };
int ret;
 
BUG_ON(reg  ISL1208_REG_USR2);
BUG_ON(reg + len  ISL1208_REG_USR2 + 1);
 
-   ret = i2c_transfer(client-adapter, msgs, 2);
-   if (ret  0)
-   ret = 0;
+   if (i2c_check_functionality(client-adapter, I2C_FUNC_I2C)) {
+   u8 reg_addr[1] = { reg };
+   struct i2c_msg msgs[2] = {
+   {client-addr, 0, sizeof(reg_addr), reg_addr}
+   ,
+   {client-addr, I2C_M_RD, len, buf}
+   };
+
+   ret = i2c_transfer(client-adapter, msgs, 2);
+   if (ret  0)
+   ret = 0;
+   } else {
+   int idx;
+   ret = i2c_smbus_read_byte_data(client, reg);
+   if (ret  0)
+   return ret;
+   buf[0] = ret;
+   for (idx = 1; idx  len; idx++) {
+   ret = i2c_smbus_read_byte(client);
+   if (ret  0)
+   return ret;
+   buf[idx] = ret;
+   }
+   }
return ret;
 }
 
@@ -88,21 +103,32 @@ static int
 isl1208_i2c_set_regs(struct i2c_client *client, u8 reg, u8 const buf[],
 unsigned len)
 {
-   u8 i2c_buf[ISL1208_REG_USR2 + 2];
-   struct i2c_msg msgs[1] = {
-   {client-addr, 0, len + 1, i2c_buf}
-   };
-   int ret;
+   int ret = 0;
 
BUG_ON(reg  ISL1208_REG_USR2);
BUG_ON(reg + len  ISL1208_REG_USR2 + 1);
 
-   i2c_buf[0] = reg;
-   memcpy(i2c_buf[1], buf[0], len);
+   if (i2c_check_functionality(client-adapter, I2C_FUNC_I2C)) {
+   u8 i2c_buf[ISL1208_REG_USR2 + 2];
+   struct i2c_msg msgs[1] = {
+   {client-addr, 0, len + 1, i2c_buf}
+   };
+
+   i2c_buf[0] = reg;
+   memcpy(i2c_buf[1], buf[0], len);
 
-   ret = i2c_transfer(client-adapter, msgs, 1);
-   if (ret  0)
-   ret = 0;
+   ret = i2c_transfer(client-adapter, msgs, 1);
+   if (ret  0)
+   ret = 0;
+   } else {
+   int idx;
+   for (idx = 0; idx  len; idx++) {
+   ret = i2c_smbus_write_byte_data(client, reg + idx,
+   buf[idx]);
+   if (ret  0)
+   return ret;
+   }
+   }
return ret;
 }
 
@@ -622,7 +648,9 @@ isl1208_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
int rc = 0;
struct rtc_device *rtc;
 
-   if (!i2c_check_functionality(client-adapter, I2C_FUNC_I2C))
+   if (!i2c_check_functionality(client-adapter, I2C_FUNC_I2C) 
+   !i2c_check_functionality(client-adapter, I2C_FUNC_SMBUS_BYTE |
+I2C_FUNC_SMBUS_BYTE_DATA))
return -ENODEV;
 
if (isl1208_i2c_validate_client(client)  0)
-- 
1.7.7

--
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] max6875: Discard obsolete detect method

2009-09-22 Thread Ben Gardner
On Sun, Sep 20, 2009 at 5:07 AM, Jean Delvare kh...@linux-fr.org wrote:
 There is no point in implementing a detect callback for the MAX6875, as
 this device can't be detected. It was there solely to handle force
 module parameters to instantiate devices, but now we have a better sysfs
 interface that can do the same.

 So we can get rid of the ugly module parameters and the detect callback.
 This basically divides the binary module size by 2.

 Signed-off-by: Jean Delvare kh...@linux-fr.org
 Cc: Ben Gardner gardner@gmail.com

Thanks for taking care of this.

Acked-by: Ben Gardner gardner@gmail.com

Ben
--
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/chips: move max6875 to drivers/misc/eeprom

2009-05-02 Thread Ben Gardner
Wolfram Sang wrote:
 This driver only reads the user EEPROM of that chip, so we can move it
 to the eeprom-directory in order to further clean up (and later remove)
 drivers/i2c/chips.
 
 The Kconfig text was updated to match the current functionality,
 dropping the meanwhile obsoleted parts.
 
 Defconfigs have been adapted.
 
 Signed-off-by: Wolfram Sang w.s...@pengutronix.de
 Cc: Ben Gardner gardner@gmail.com
 Cc: Jean Delvare kh...@linux-fr.org
 ---
 
 This is against linus-git of today. Jean, do you think such a patch 
 can make it at this point of the release cycle? It is a bit
 annoying because of all the defconfigs.
 
 Ben, are you fine with these changes?

I'm fine with the changes.
Thanks for taking care of this.

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