{"action":"closed","issue":{"url":"https://api.github.com/repos/fivdi/i2c-bus/issues/25","repository_url":"https://api.github.com/repos/fivdi/i2c-bus","labels_url":"https://api.github.com/repos/fivdi/i2c-bus/issues/25/labels{/name}","comments_url":"https://api.github.com/repos/fivdi/i2c-bus/issues/25/comments","events_url":"https://api.github.com/repos/fivdi/i2c-bus/issues/25/events","html_url":"https://github.com/fivdi/i2c-bus/issues/25","id":181112812,"number":25,"title":"w1_ds28e17 interoperarability issue when using scan or scanSync functions","user":{"login":"gundrygs","id":15112766,"avatar_url":"https://avatars.githubusercontent.com/u/15112766?v=3","gravatar_id":"","url":"https://api.github.com/users/gundrygs","html_url":"https://github.com/gundrygs","followers_url":"https://api.github.com/users/gundrygs/followers","following_url":"https://api.github.com/users/gundrygs/following{/other_user}","gists_url":"https://api.github.com/users/gundrygs/gists{/gist_id}","starred_url":"https://api.github.com/users/gundrygs/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gundrygs/subscriptions","organizations_url":"https://api.github.com/users/gundrygs/orgs","repos_url":"https://api.github.com/users/gundrygs/repos","events_url":"https://api.github.com/users/gundrygs/events{/privacy}","received_events_url":"https://api.github.com/users/gundrygs/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2016-10-05T10:05:38Z","updated_at":"2016-10-06T11:13:51Z","closed_at":"2016-10-06T11:13:51Z","body":"The DS28E17 chip from Maxim is a 1-Wire to I2C bridge - details here:\r\n[https://www.maximintegrated.com/en/products/interface/controllers-expanders/DS28E17.html](url)\r\n \r\nA kernel driver for Linux has been created by Jan Kandziora, and we are using this on Raspbian Jessie 4.4.22  with great results - details here: [https://github.com/ianka/w1_ds28e17](url)\r\n\r\nThis presents an additional i2c device in Linux, in our case /dev/i2c-3, which can be addressed using the i2c-bus library. When doing a bus scan, i2c-bus tries a I2C_FUNC_SMBUS_READ_BYTE on each slave address in turn, from 0x03 through to 0x77. The native i2c device /dev/i2c-1 replies with an EIO error code for unoccupied slave addresses, but the w1_ds28e17 replies with ENXIO, which causes the i2c-bus library to throw an exception. I have discussed this with Jan, and agree with him that this is in fact correct behaviour - see the points he makes below:\r\n\r\n_\"linux/Documentation/i2c/fault-codes says:\r\n\r\nENXIO\r\n  Returned by I2C adapters to indicate that the address phase\r\n  of a transfer didn't get an ACK.  While it might just mean\r\n  an I2C device was temporarily not responding, usually it\r\n  means there's nothing listening at that address.\r\n\r\n  Returned by driver probe() methods to indicate that they\r\n  found no device to bind to.  (ENODEV may also be used.)\r\n\r\nSo I have to assume returning ENXIO is correct behaviour. I'm pretty sure the other drivers will get patched someday.\r\n\r\nThe reason why w1_ds28e17 doesn't return EIO on I2C addressing failed is the w1 subsystem returns EIO when addressing the DS28E17 fails. If both returned the same error code, you had no chance to find out if it was the DS28E17 missing or the I2C slave.\"_\r\n\r\nWould you consider amending the i2c-bus library behaviour to ignore returned ENXIO error codes in these circumstances ?\r\n"}}
{"actor":{"display_login":"fivdi"}}