lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2467231.EbVekJun1R@wuerfel>
Date:   Mon, 07 Nov 2016 21:08:27 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     John Garry <john.garry@...wei.com>
Cc:     linux-arm-kernel@...ts.infradead.org,
        Anurup M <anurupvasu@...il.com>, anurup.m@...wei.com,
        linux-kernel@...r.kernel.org, mark.rutland@....com,
        shyju.pv@...wei.com, gabriele.paoloni@...wei.com,
        will.deacon@....com, linuxarm@...wei.com, xuwei5@...ilicon.com,
        zhangshaokun@...ilicon.com, sanil.kumar@...ilicon.com,
        tanxiaojun@...wei.com, shiju.jose@...wei.com
Subject: Re: [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ