From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751495AbdJCVt3 (ORCPT ); Tue, 3 Oct 2017 17:49:29 -0400 Received: from mail-oi0-f46.google.com ([209.85.218.46]:46358 "EHLO mail-oi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751120AbdJCVt1 (ORCPT ); Tue, 3 Oct 2017 17:49:27 -0400 X-Google-Smtp-Source: AOwi7QCIpASe1kyxYWzky579i2UShpj8WrEXt9Y4NCT/dw1gNrhgmp0nc/+oIpZNyrhDVkRYZDSEWw== Date: Tue, 3 Oct 2017 16:49:25 -0500 From: Rob Herring To: Gregory CLEMENT Cc: Chris Packham , Kalyan Kinthada , "devicetree@vger.kernel.org" , "wsa@the-dreams.de" , "pawel.moll@arm.com" , "mark.rutland@arm.com" , "ijc+devicetree@hellion.org.uk" , "galak@codeaurora.org" , "linux-i2c@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] dt-bindings: i2c: Add armada-38x i2c binding Message-ID: <20171003214925.353u7l35jvnergsr@rob-hp-laptop> References: <20170922020429.20941-1-kalyan.kinthada@alliedtelesis.co.nz> <87377fmbpw.fsf@free-electrons.com> <1506289460890.34765@alliedtelesis.co.nz> <87lgl1ishv.fsf@free-electrons.com> <5376f24bf4c540088ce6432097b5cb51@svr-chch-ex1.atlnz.lc> <87efqsiok3.fsf@free-electrons.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87efqsiok3.fsf@free-electrons.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 27, 2017 at 09:33:00AM +0200, Gregory CLEMENT wrote: > Hi Chris, > > On mer., sept. 27 2017, Chris Packham wrote: > > > Hi Gregory, > > > > On 27/09/17 00:56, Gregory CLEMENT wrote: > >> Hi Kalyan, > >> > >> Please try avoid top-posting. > >> > >> On dim., sept. 24 2017, Kalyan Kinthada wrote: > >> > >>> Hi Gregory, > >>> > >>> I got this information from Armada-38x functional errata document. > >> > >> OK but in any case just adding a new compatible was not enough you have > >> to update the driver in the same time, however for this case we won't > >> need it, see below. > >> > >>> > >>> I can add the "marvell,mv78230-i2c" compatible string to the appropriate device tree files > >>> but the i2c-mv64xxx driver enables an additional feature (offload i2c transactions) > >>> based on the compatible string "marvell,mv78230-i2c". > >>> > >>> I am not sure if this feature (offload i2c transactions) should be enabled for Armada-38x devices. > >>> That is the reason I felt for the need of a new compatible string > >>> specifically for Armada-38x SoCs. > >> > >> Indeed the Armada-38x SoCs does not support hardware offloading (at > >> least according the datasheet). But it happens that in the earlier > >> version of the Armada XP the hardware offloading was buggy, so we > >> introduced a compatible for this case: marvell,mv78230-a0-i2c. This > >> compatible enable the errata fix but not the offloading feature. That > >> means that it is exactly the compatible you need for Armada 38x (and > >> Armada 39x and 375 I think). > > > > The "mv78230-a0-i2c" dt-binding has the following note > > > > Note: Only use "marvell,mv78230-a0-i2c" for a > > very rare, initial version of the SoC which > > had broken offload support. Linux > > auto-detects this and sets it appropriately. > > > > If we are going to re-use this binding for armada-38x we should probably > > remove this note. Personally my preference would be an armada-38x > > Updating the documentation is the right thing to do yes. > > > > compatible string (or 370 if that's the common base of these SoCs). But > > of course we'll go with whatever your preference is as maintainer. > > If the IP is compatible then there is no reason to add a new one, else > we will end with a compatible for each SoC and the compatible property > will just loose its meaning. If you all had added compatibles for each SoC in the first place, then we wouldn't be having this dicussion. Rob