From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752176AbcKGUJW (ORCPT ); Mon, 7 Nov 2016 15:09:22 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:55155 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750905AbcKGUJU (ORCPT ); Mon, 7 Nov 2016 15:09:20 -0500 From: Arnd Bergmann To: John Garry Cc: linux-arm-kernel@lists.infradead.org, Anurup M , anurup.m@huawei.com, linux-kernel@vger.kernel.org, mark.rutland@arm.com, shyju.pv@huawei.com, gabriele.paoloni@huawei.com, will.deacon@arm.com, linuxarm@huawei.com, xuwei5@hisilicon.com, zhangshaokun@hisilicon.com, sanil.kumar@hisilicon.com, tanxiaojun@huawei.com, shiju.jose@huawei.com Subject: Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Date: Mon, 07 Nov 2016 21:08:27 +0100 Message-ID: <2467231.EbVekJun1R@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <2a8dc40f-be75-b010-3ec7-6912f02e3c90@huawei.com> References: <1478101374-18778-1-git-send-email-anurup.m@huawei.com> <2127881.qmAR1XgW9F@wuerfel> <2a8dc40f-be75-b010-3ec7-6912f02e3c90@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:OaJQ/VDe/ttD5YHv0y4szGNEVXg1W8M+CE338cUgIX43mMcOQxW XM2qvcfvzqZat/T4GsMeMayyZZa/yP6lp1H+Dfh9QeXpNhJrnoBgRsA6zXA0lzrn3ZnkCTA A2jqpozVUfTsNQGvsoM5qp31toDG6w4jR8zruaPXLy/LNiGoQEFW59stMX9/oIwsQuB2CKR yySiAg37N9N9sxKbFW14g== X-UI-Out-Filterresults: notjunk:1;V01:K0:Q7t4wCSFQyM=:nXUI6QcICrQEc5DVeoh24f XaSuEIN48xNgc3011CYncqgWrGwnwWTfF8PLfBhaWWO/W1qKPLZZOHrVd0t6IRyhvOXWIYela HELemw/F+jApQV8nAoOYohGvx3+p2QJBnD9AgCiQ2zA+RW1AQxkl1iYoLKBUx7hXTbdLEfDvY xoqbznOUatuq18NOl8eIBnn+J+SGsWc0WHsCG8PBxbuLNWrIG60WW0nME33TH7REoU46rZlck IfaL9YyKN7OMji4Rt58PoNS1xJJjWu/nMqeqwi6hiSBDoW1iWUQ58M1RFhJ5NGrmExH+XojLU sMGNdxHSMoLWh6kXgcLtrrlZpqQka0/4itv1YcZvVFCh0NZIB7Oj9XdwilVPM/N93tc8MrmxN xG2ZgaSHHawgV7puWwmyW06cRjk8sGOCcrsEEyhWEx1UK/YG21bnzR7RXdrKFB3p938NTcwH9 BSdgh9OVWHUlBDOlJVvB9BRPB8akUCVOMwx+J9vxaW4aj5q8ln8fFqnvhPaIyoxYPihYIQr3V kd8dVWgBqKQhJhJa6bvsOZdDzcrVSGy6qrvrYpp1Oo0q5aeNbO52DaVOFLbwvCS3rmC78Gxa8 yBtAvJ11VFDd4+Sz7mkHwFTaUST8auWGUlNEfyb12k40Sb0SMGApmX9jab2fO39dQwNv/nAjB WdtxCZCucDDMoELTACYhP7ihlPBFkiUSPohJhya8dwW3BdG99WMWPs6NwDszNpt2YD9rpCK2V T32DWlkufWzZMLCo Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, November 7, 2016 2:15:10 PM CET John Garry wrote: > > Hi Arnd, > > The new bus type tries to model the djtag in a similar way to I2C/USB > driver arch, where we have a host bus adapter and child devices attached > to the bus. The child devices are bus driver devices and have bus > addresses. We think of the djtag as a separate bus, so we are modelling > it as such. > > The bus driver offers a simple host interface for clients to read/write > to the djtag bus: bus accesses are hidden from the client, the host > drives the bus. Ok, in that case we should probably start out by having a bus specific DT binding, and separating the description from that of the bus master device. I'd suggest requiring #address-cells=<1> and #size-cells=<0> in the master node, and listing the children by reg property. If the address is not easily expressed as a single integer, use a larger #address-cells value. Another option that we have previously used was to actually pretend that a vendor specific bus is an i2c bus and use the i2c probing infrastructure, but that only makes sense if the software side closely resembles i2c (this was the case for Allwinner I think, but I have not looked at your driver in enough detail to know if it is true here as well). Arnd