From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751575AbbJBXF2 (ORCPT ); Fri, 2 Oct 2015 19:05:28 -0400 Received: from mail.lysator.liu.se ([130.236.254.3]:51674 "EHLO mail.lysator.liu.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751243AbbJBXF1 (ORCPT ); Fri, 2 Oct 2015 19:05:27 -0400 To: Linux Kernel Mailing List Cc: Wolfram Sang , Christian Gmainer , linux-arm-kernel@lists.infradead.org, Ludovic Desroches From: Peter Rosin Subject: Regression: at24 eeprom writing Message-ID: <560F0DB1.2020101@lysator.liu.se> Date: Sat, 3 Oct 2015 01:05:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! I recently upgraded from the atmel linux-3.18-at91 kernel to vanilla 4.2 and everything seemed fine. Until I tried to write to the little eeprom chip. I then tried the linux-4.1-at91 kernel and that suffers too. The symptoms are that it seems like writes get interrupted, and restarted again without properly initializing everything again. Inspecting the i2c bus during these fails gets me something like this (int hex) when I echo abcdefghijklmnopqr > /sys/bus/i2c/devices/0-0050/eeprom S a0 00 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 P S a0 10 (clk and data low for a "long" time) 10 71 72 0a P Notice how the address byte in the second chunk (10) is repeated after the strange event on the i2c bus. I looked around and found that if I revert a839ce663b3183209fdf7b1fc4796bfe2a4679c3 "eeprom: at24: extend driver to allow writing via i2c_smbus_write_byte_data" eeprom writing starts working again. AFAICT, the i2c-at91 bus driver makes the eeprom driver use the i2c_transfer code path both with that patch and with it reverted, so I sadly don't see why the patch makes a difference. I'm on a board that is based on the sama5d31 evaluation kit, with a NXP SE97BTP,547 chip and this in the devicetree: i2c0: i2c@f0014000 { status = "okay"; jc42@18 { compatible = "jc42"; reg = <0x18>; }; eeprom@50 { compatible = "24c02"; reg = <0x50>; pagesize = <16>; }; }; Any ideas? Cheers, Peter