linux-kernel - Re: [PATCH v3 1/8] rsb: Add generic Reduced Serial Bus (RSB) controller binding documentation

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] [day] [month] [year] [list]

Message-ID: <CAGb2v65dai3At24HhUY9h-dCs1jEXiwqgOMefziokJXa00Ercw@mail.gmail.com>
Date:	Mon, 14 Sep 2015 15:32:11 +0800
From:	Chen-Yu Tsai <wens@...e.org>
To:	Rob Herring <robherring2@...il.com>
Cc:	Chen-Yu Tsai <wens@...e.org>, Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Mark Brown <broonie@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-sunxi <linux-sunxi@...glegroups.com>,
	Hans de Goede <hdegoede@...hat.com>,
	Meng Zhang <kevin@...winnertech.com>,
	Shuge <shuge@...winnertech.com>,
	Meng Zhang <kevin.z.m.zh@...il.com>
Subject: Re: [PATCH v3 1/8] rsb: Add generic Reduced Serial Bus (RSB)
 controller binding documentation

On Mon, Aug 24, 2015 at 6:43 AM, Rob Herring <robherring2@...il.com> wrote:
> On Tue, Aug 18, 2015 at 11:20 PM, Chen-Yu Tsai <wens@...e.org> wrote:
>> Reduced Serial Bus is a proprietary 2-line push-pull serial bus
>> supporting multiple slave devices.
>>
>> It was developed by Allwinner, Inc. and used by Allwinner and X-Powers,
>> Inc. for their line of PMICs and other peripheral ICs.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@...e.org>
>> ---
>>  Documentation/devicetree/bindings/rsb/rsb.txt | 50 +++++++++++++++++++++++++++
>>  1 file changed, 50 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/rsb/rsb.txt
>>
>> diff --git a/Documentation/devicetree/bindings/rsb/rsb.txt b/Documentation/devicetree/bindings/rsb/rsb.txt
>> new file mode 100644
>> index 000000000000..0b027948ca9c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/rsb/rsb.txt
>> @@ -0,0 +1,50 @@
>> +Reduced Serial Bus (RSB) Controller
>> +
>> +This document defines a generic set of bindings for use by RSB controllers.
>> +A controller is modelled in device tree as a node with zero or more child
>> +nodes, each representing a unique slave device on the bus.
>> +
>> +Required properties:
>> +
>> + - #address-cells : must be 2
>> + - #size-cells : must be 0
>> +
>> +Optional properties:
>> +
>> + - clock-frequency : Desired bus clock frequency in Hz. Maximum is 20 MHz.
>> +
>> +Child nodes:
>> +
>> +An RSB controller node can contain zero or more child nodes representing
>> +slave devices on the bus.  Child 'reg' properties are specified as a
>> +runtime address, hardware address pair. The hardware address is hardwired
>> +in the device, which can normally be found in the datasheet. The runtime
>> +address is set by software. No 2 devices on the same bus shall have the
>> +same runtime address.
>> +
>> +Valid runtime addresses - There are only 15 valid runtime addresses:
>> +
>> +    0x17, 0x2d, 0x3a, 0x4e, 0x59, 0x63, 0x74, 0x8b,
>> +    0x9c, 0xa6, 0xb1, 0xc5, 0xd2, 0xe8, 0xff
>> +
>> +It is highly recommended that one choose the same runtime addresses as
>> +vendor BSPs use so that a) the addresses remain the same across different
>> +software systems, and b) addresses of supported and listed slave devices
>> +don't conflict with unsupported or not yet listed devices.
>
> I fail to understand why the run-time address belongs in DT or why
> alignment to vendor BSP matters? I can see the desire to align DTs if
> the vendor OS was dependent on having this information. Having to
> access the vendor OS to determine what address to pick does not seem
> like the right way to write a DTS. It seems to me that the RSB bus
> driver should allocate run-time addresses dynamically.

I agree it seems better that the driver should allocate them dynamically.
However my attempts to reset the runtime addresses all fail, with the
device in question rejecting the request.

I'll run some more tests. Another way would be for the driver to test
if the device was already allocated an address, and just use that. If
not, then just allocate one to it. The implementation is a bit more
complicated, as there's no lookup function.

But if we cannot reliably reset the runtime addresses, I don't see
any alternative to putting the address in the DT. Most of the use cases
we want to support are PMICs, which are initialized by the boot loader.


Regards
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/