Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938661AbcKXJt2 (ORCPT ); Thu, 24 Nov 2016 04:49:28 -0500 Received: from mail-io0-f176.google.com ([209.85.223.176]:34234 "EHLO mail-io0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936468AbcKXJtZ (ORCPT ); Thu, 24 Nov 2016 04:49:25 -0500 MIME-Version: 1.0 In-Reply-To: <8737ihmctr.fsf@free-electrons.com> References: <4031579.CBE32NHUoW@wuerfel> <877f7tmduw.fsf@free-electrons.com> <28082657.RK5ubAe11Q@wuerfel> <8737ihmctr.fsf@free-electrons.com> From: Marcin Wojtas Date: Thu, 24 Nov 2016 10:49:23 +0100 Message-ID: Subject: Re: [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller To: Gregory CLEMENT Cc: Arnd Bergmann , "linux-arm-kernel@lists.infradead.org" , Jimmy Xu , Andrew Lunn , Ulf Hansson , Romain Perier , Liuliu Zhao , Peng Zhu , "linux-kernel@vger.kernel.org" , Nadav Haklai , Ziji Hu , Victor Gu , Doug Jones , Jisheng Zhang , Yehuda Yitschak , Xueping Liu , Hilbert Zhang , Shiwu Zhang , Yu Cao , Sebastian Hesselbarth , "devicetree@vger.kernel.org" , Jason Cooper , Hanna Hawa , Kostya Porotchkin , Ryan Gao , "Wei(SOCP) Liu" , Thomas Petazzoni , Keji Zhang , "Jack(SH) Zhu" , "linux-mmc@vger.kernel.org" , Adrian Hunter , Wilson Ding Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1487 Lines: 40 Hi Gregory, 2016-11-24 10:44 GMT+01:00 Gregory CLEMENT : > Hi Arnd, > > On jeu., nov. 24 2016, Arnd Bergmann wrote: > >> On Thursday, November 24, 2016 10:22:31 AM CET Gregory CLEMENT wrote: >>> >>> I don't have an option for mmc in general, but using child node do not >>> fit at all the xenon controller. >>> >>> For this controller each slot has its own set of register, so there is >>> no common ressource to share so no advantage to use it. Using child node >>> in our case will just make the code more complex for no benefit. >> >> If every slot has its own registers, what is it that makes up the >> 'controller'? It sounds to me that you just have to adjust the terminology >> and talk about multiple controllers then, with one slot per controller. >> > > I agree and actually there were some words about in at the begining of > the binding: > > "A single Xenon IP can support multiple slots. > Each slot acts as an independent SDHC. It owns independent resources, such > as register sets clock and PHY. > Each slot should have an independent device tree node." > > All the confusion came from the fact that we still need to identify a > slot ID. For an obscure reason the hardware can't guess the slot ID from > the address register." > How about to avoid confusion, by simply renaming this number to port-id/xenon-id or anything else but slot? I guess this may allow to avoid some misunderstandings. Best regards, Marcin