Received: by 10.223.164.202 with SMTP id h10csp333197wrb; Thu, 30 Nov 2017 11:04:08 -0800 (PST) X-Google-Smtp-Source: AGs4zMarK8VuwbJcT4uLFq+MLCBHpKcN/pKWBPsUnZUdMx6/kKzA0cGt/Q2VrKeP1p+Hwoho1UXp X-Received: by 10.159.194.138 with SMTP id y10mr3617108pln.85.1512068648491; Thu, 30 Nov 2017 11:04:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512068648; cv=none; d=google.com; s=arc-20160816; b=VgXMb/s8uFgMb/CJzQlUZT+TNn+fLmZzIeP0hcyXFgZuEeNDZhfuD8GFanGPNsNSG2 8xL++7ttsetJOuMeijLqMC79Tvmd9+x9k4YVpdxS/TRrq/UpuQHPRIbT33c6MNOksrWd lUMdUGrLBckvipP33AHtP9Ho43YUhNpgrpoR3MTp/o/ndPzTrFCtl5kpk7zPpBnwCBdz iImVYD8t6lihqCX5Km9IngRSHx4YzjUZdQJ+PyzVIa1PCXmqsW+pzbzabb2plOujxrfK RrhPobiOu8mdyVxt380RFSTYGxicQvcwHq/QVTs4GjbhmtTA/02H6MkeU7DgU+99vTPL pDMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=83DNfIgDuLjKQAdEgZJJcz7bC1WIOxVpwCPz0NlgR78=; b=HER+9ngPAALX03hTDbJ3j2GwJjEZzg6HbLs2hQjHFED5EwEG6wkZpNd0wrkUJxf5hl mXrl7N+vuqjFcXYEfAxm+ZR7Pbb5M7OlUr1n7OSQWLGdQNOJSGCeZojDW1LbrIJYdqsx X0DGSYRpOnsdK9Tq/StPh5XIM5I4oWFKqqU4ypoKeLlAIIpJ+amv/8TC74OWlL0NHQ8z JXNGeUAea0Y0quVgp06BiJLhRFhBGCtnDYa/qQP/kRdV1LgU2sj5ungUJRp6nGAl9oqf PLsi8DD+hNs34fWekop4bfxe4BsfnLRLwRuxwzO3kD1Ihgafe6oIgQpfnS4PLWwiLSTz 4zdg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f5si3391609pgo.453.2017.11.30.11.03.54; Thu, 30 Nov 2017 11:04:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751706AbdK3TDa (ORCPT + 99 others); Thu, 30 Nov 2017 14:03:30 -0500 Received: from mail.arcx.com ([184.94.50.18]:47951 "EHLO WEBMAIL.arcx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751096AbdK3TD3 (ORCPT ); Thu, 30 Nov 2017 14:03:29 -0500 Received: from trappist.arcx.com (192.168.2.155) by WEBMAIL.arcx.com (192.168.2.64) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 30 Nov 2017 14:03:27 -0500 From: Sven Van Asbroeck To: , , CC: , , Subject: BUG: support for at24 multi-slave-address eeproms is broken. Date: Thu, 30 Nov 2017 14:03:23 -0500 Message-ID: <1512068603-12378-1-git-send-email-svendev@arcx.com> X-Mailer: git-send-email 1.9.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [192.168.2.155] X-ClientProxiedBy: webmail.arcx.com (192.168.2.64) To WEBMAIL.arcx.com (192.168.2.64) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Summary ------- Some at24 eeproms have multiple i2c slave addresses. A patch introduced between 4.14-rc5 and 4.14-rc6 breaks support for these eeproms: reads/writes which start outside the first slave no longer work. 98e8201039afad5d2af87df9ac682f62f69c0c2f (eeprom: at24: enable runtime pm support) How to reproduce ---------------- - I'm using the latest mainline at24 driver (4.15-rc1) - I have a 24AA16/24LC16B on board, which is a 2048-byte eeprom, made up of 8x 256-byte internal eeproms, all with their own i2c slave address. Base i2c address is 0x50, so this results in the following slave addresses: 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57 of 256 bytes each. $ ls -l /sys/bus/i2c/devices/1-0050/eeprom -rw------- 1 root root 2048 Nov 30 13:16 /sys/bus/i2c/devices/1-0050/eeprom Reading from the beginning to the end in one go works just fine: $ hexdump -C /sys/bus/i2c/devices/1-0050/eeprom 00000000 f8 6e cf 01 ff 01 00 00 03 00 58 41 18 00 00 00 |.n........XA....| 00000010 53 61 74 20 4d 61 72 20 31 32 20 31 32 3a 35 35 |Sat Mar 12 12:55| 00000020 3a 31 32 20 32 30 31 36 01 00 58 41 0f 00 00 00 |:12 2016..XA....| 00000030 41 58 4d 2d 55 50 33 32 39 32 2d 30 38 32 34 00 |AXM-UP3292-0824.| 00000040 02 00 58 41 0d 00 00 00 41 58 53 2d 55 50 33 4b |..XA....AXS-UP3K| 00000050 2d 30 32 30 34 00 00 00 04 00 58 41 09 00 00 00 |-0204.....XA....| 00000060 55 4e 54 31 34 30 30 42 34 00 00 00 0a 00 58 41 |UNT1400B4.....XA| 00000070 01 00 00 00 32 00 00 00 09 00 58 41 01 00 00 00 |....2.....XA....| 00000080 31 00 00 00 01 00 00 00 32 00 00 00 01 00 00 00 |1.......2.......| 00000090 32 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff |2...............| 000000a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| * 00000800 Reading from somewhere in the middle (outside of first slave) gives EACCESS: $ dd if=/sys/bus/i2c/devices/1-0050/eeprom bs=1 skip=520 count=20 dd: /sys/bus/i2c/devices/1-0050/eeprom: Permission denied Reading from somewhere in the middle (INSIDE of first slave) still works: $ dd if=/sys/bus/i2c/devices/1-0050/eeprom bs=1 skip=20 count=20 | hexdump -C 00000000 4d 61 72 20 31 32 20 31 32 3a 35 35 3a 31 32 20 |Mar 12 12:55:12 | 00000010 32 30 31 36 |2016| 00000014 Additional questions for the patch authors ------------------------------------------ 1. why is there a need to add pm_runtime support to a series of chips (at24) which do not have any power management registers, hardware or support ? 2. why is the at24's pm_runtime support operating on its parent i2c bus? Why can't the parent i2c bus driver be in charge of its own runtime pm? From 1584396276087871128@xxx Sat Nov 18 09:40:35 +0000 2017 X-GM-THRID: 1584396276087871128 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread