From: Arnd Bergmann <arnd@arndb.de>
To: John Garry <john.garry@huawei.com>
Cc: linux-arm-kernel@lists.infradead.org,
Anurup M <anurupvasu@gmail.com>,
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 [thread overview]
Message-ID: <2467231.EbVekJun1R@wuerfel> (raw)
In-Reply-To: <2a8dc40f-be75-b010-3ec7-6912f02e3c90@huawei.com>
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
next prev parent reply other threads:[~2016-11-07 20:09 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-02 15:42 [PATCH v1 00/11] perf: arm64: Support for Hisilicon SoC Hardware event counters Anurup M
2016-11-02 15:42 ` [PATCH v1 01/11] arm64: MAINTAINERS: hisi: Add hisilicon SoC PMU support Anurup M
2016-11-02 15:42 ` [PATCH v1 02/11] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Sysctrl and Djtag dts bindings Anurup M
2016-11-02 15:42 ` [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver Anurup M
2016-11-03 1:59 ` kbuild test robot
2016-11-07 13:26 ` Arnd Bergmann
2016-11-07 14:15 ` John Garry
2016-11-07 20:08 ` Arnd Bergmann [this message]
2016-11-08 11:23 ` John Garry
2016-11-08 11:45 ` Arnd Bergmann
2016-11-08 13:49 ` John Garry
2016-11-08 15:10 ` Arnd Bergmann
2016-11-08 15:17 ` John Garry
2016-11-09 10:44 ` Anurup M
2016-11-08 15:51 ` Anurup M
2016-11-09 9:06 ` John Garry
2016-11-11 10:35 ` Anurup M
2016-11-08 7:02 ` Tan Xiaojun
2016-11-08 7:38 ` Anurup M
2016-11-08 11:43 ` Arnd Bergmann
2016-11-08 13:46 ` Anurup M
2016-11-08 15:08 ` Arnd Bergmann
2016-11-09 4:28 ` Anurup M
2016-11-09 21:40 ` Arnd Bergmann
2016-11-11 10:23 ` Anurup M
2016-11-02 15:42 ` [PATCH v1 04/11] Documentation: perf: hisi: Documentation for HIP05/06/07 PMU event counting Anurup M
2016-11-02 15:42 ` [PATCH v1 05/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU Anurup M
2016-11-02 15:42 ` [PATCH v1 06/11] perf: hisi: Update Kconfig for Hisilicon PMU support Anurup M
2016-11-02 15:42 ` [PATCH v1 07/11] perf: hisi: Add support for Hisilicon SoC event counters Anurup M
2016-11-02 15:42 ` [PATCH v1 08/11] perf: hisi: Add sysfs attributes for L3 cache(L3C) PMU Anurup M
2016-11-02 15:42 ` [PATCH v1 09/11] perf: hisi: Miscellanous node(MN) event counting in perf Anurup M
2016-11-02 15:42 ` [PATCH v1 10/11] perf: hisi: Support for Hisilicon DDRC PMU Anurup M
2016-11-02 15:42 ` [PATCH v1 11/11] dts: arm64: hip06: Add Hisilicon SoC PMU support Anurup M
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2467231.EbVekJun1R@wuerfel \
--to=arnd@arndb.de \
--cc=anurup.m@huawei.com \
--cc=anurupvasu@gmail.com \
--cc=gabriele.paoloni@huawei.com \
--cc=john.garry@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mark.rutland@arm.com \
--cc=sanil.kumar@hisilicon.com \
--cc=shiju.jose@huawei.com \
--cc=shyju.pv@huawei.com \
--cc=tanxiaojun@huawei.com \
--cc=will.deacon@arm.com \
--cc=xuwei5@hisilicon.com \
--cc=zhangshaokun@hisilicon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox