From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753238AbbBYTb6 (ORCPT ); Wed, 25 Feb 2015 14:31:58 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:64725 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753013AbbBYTb4 (ORCPT ); Wed, 25 Feb 2015 14:31:56 -0500 From: Arnd Bergmann To: Chen-Yu Tsai Cc: Wolfram Sang , Maxime Ripard , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , linux-i2c@vger.kernel.org, linux-arm-kernel , linux-kernel , devicetree , linux-sunxi , Hans de Goede Subject: Re: [PATCH 2/4] i2c: sunxi: Add Reduced Serial Bus (RSB) DT bindings documentation Date: Wed, 25 Feb 2015 17:10:49 +0100 Message-ID: <2832810.NHVTmhf5rK@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1424773744-15106-1-git-send-email-wens@csie.org> <16025407.hQRFhlbHKD@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:uZLTWL7mhOlEN8fo25cZPQj0+TXYEREGDhXoPwcz3si0dCOol86 Upmcs0+cDmOdIrLa9yypXf8MKRdAeixHLd6/k6iKdJClU7ofLid5vKb4YDu7kUt4dV1V8GX wCdVWmVJHWh5WS3boRBYD8UaKb+HsQN7HRi5zcAi4cagu1wsXLPGNFV7ZS3L0JEqT8kQilD wDBfmRlKEYrGJ/cxa1nlQ== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 24 February 2015 22:32:57 Chen-Yu Tsai wrote: > On Tue, Feb 24, 2015 at 10:17 PM, Arnd Bergmann wrote: > > On Tuesday 24 February 2015 22:01:26 Chen-Yu Tsai wrote: > >> On Tue, Feb 24, 2015 at 6:37 PM, Arnd Bergmann wrote: > >> > On Tuesday 24 February 2015 18:29:02 Chen-Yu Tsai wrote: > >> >> > >> >> + rsb@01f03400 { > >> >> + compatible = "allwinner,sun8i-a23-rsb"; > >> >> + reg = <0x01f03400 0x400>; > >> >> + interrupts = <0 39 4>; > >> >> + clocks = <&apb0_gates 3>; > >> >> + clock-frequency = <3000000>; > >> >> + resets = <&apb0_rst 3>; > >> >> + > >> >> + axp223: pmic@2d { > >> >> + compatible = "x-powers,axp223", "x-powers,axp221"; > >> >> + reg = <0x2d>; > >> >> + allwinner,rsb-hw-addr = <0x3e3>; > >> >> + > >> >> + /* ... */ > >> >> + }; > >> >> + }; > >> > >> > I don't really understand the need for having two addresses (runtime > >> > and hardware). Could the runtime address be configured at runtime? > >> > >> You can, though the driver doesn't support this. I don't think the > >> I2C subsystem allows arbitrary device insertion during normal > >> operation, but maybe i2c-dev? I've tried using different addresses > >> for devices so they do get changed during the probe phase, just > >> to be sure that the code works, and it's not just sitting at > >> the address the bootloader used. > >> > >> In any case, the distinction is more like burnt-in or hardwired > >> addresses vs software configurable addresses. > > > > The simplest binding would the probably be to only put the > > hardware address into the 'reg' property and always assign the > > logical addresses dynamically. > > > > Would that add a lot of complexity or does it have any other > > downsides? > > The hardware address is 12 bits wide. Any address higher than > 0x3ff will be rejected by the I2C core. The AC100 is at 0xe89. > > Assigning addresses dynamically means the driver has to keep > a lookup table to map the hardware address to the logical > address to issue the command to. > > There's also the issue of dynamically assigned address colliding > with unlisted devices, though I think this would only happen in > the development / bring up phase of the device. > > I think the first issue pretty much rules out putting the > hardware address into 'reg'. > > Putting the logical address in the 'reg' property allows the > user to poke unlisted devices using i2c-tools, though this > is not so useful to the average user. Ok, fair enough. Your approach seems reasonable then, but it might be helpful to add your explanation to the changelog of the patch that introduces the binding. Arnd