linux-kernel - Re: [PATCH v5 05/24] ARM: tegra: Add device-tree for ASUS Transformer EeePad TF101

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: <de357dd7-ad4b-758c-f041-b3385d164b98@gmail.com>
Date:   Fri, 10 Dec 2021 19:42:18 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Jonathan Hunter <jonathanh@...dia.com>,
        David Heidelberg <david@...t.cz>,
        Svyatoslav Ryhel <clamor95@...il.com>,
        Anton Bambura <jenneron@...tonmail.com>,
        Antoni Aloy Torrens <aaloytorrens@...il.com>,
        Nikola Milosavljevic <mnidza@...look.com>,
        Ion Agorria <ion@...rria.com>,
        Michał Mirosław <mirq-linux@...e.qmqm.pl>,
        Ihor Didenko <tailormoon@...bler.ru>,
        Andreas Westman Dorcsak <hedmoo@...oo.com>,
        Maxim Schwalm <maxim.schwalm@...il.com>,
        Raffaele Tranquillini <raffaele.tranquillini@...il.com>,
        Jasper Korten <jja2000@...il.com>,
        Thomas Graichen <thomas.graichen@...il.com>,
        Stefan Eichenberger <stefan.eichenberger@...adex.com>,
        devicetree@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 05/24] ARM: tegra: Add device-tree for ASUS Transformer
 EeePad TF101

10.12.2021 18:46, Thierry Reding пишет:
...
>> +	gpio@...0d000 {
>> +		charging-enable-hog {
>> +			gpio-hog;
>> +			gpios = <TEGRA_GPIO(R, 6) GPIO_ACTIVE_HIGH>;
>> +			output-low;
>> +		};
>> +	};
> 
> Isn't this something that we may want to change at some point? My
> understanding is that GPIO hogs are permanent, so it won't be possible
> to grab GPIO R.6 and change this.
> 
> Are there any plans to allow setting this at runtime?

I'm not aware about plans to change that charging hog.

It's not a problem to remove the hog. I don't understand why you're
saying that it's permanent. We have such hogs in Nexus7 DT for the 3G
modem pins. If we'll ever have a driver for that modem, then we will
remove those hogs, not a problem.

> [...]
>> +	i2c2: i2c@...0c400 {
>> +		status = "okay";
>> +		clock-frequency = <100000>;
>> +	};
>> +
>> +	i2cmux {
> 
> This doesn't belong here. The ordering is by unit-address and everything
> without unit-address needs to move after the nodes with unit-addresses
> and be sorted alphabetically.

Logically it belongs here, since mux uses i2c2. All other DTs do the same.

...
>> +	memory-controller@...0f400 {
>> +		nvidia,use-ram-code;
>> +
>> +		emc-tables@3 {
>> +			reg = <0x3>;
>> +
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +
>> +			lpddr2 {
>> +				compatible = "elpida,B8132B2PB-6D-F", "jedec,lpddr2-s4";
>> +				revision-id1 = <1>;
>> +				density = <2048>;
>> +				io-width = <16>;
>> +			};
>> +
>> +			emc-table@...00 {
> 
> Ugh... looking at the bindings for this the naming here is rather
> unfortunate. emc-tables@3 and emc-table@.... the top-level emc-tables
> are really tables, but the emc-table@* are really entries or rows in
> that table, not tables themselves. It's also rather unfortunate that we
> duplicate the frequency in both the "reg" and "clock-frequency"
> properties. One of them would've been enough.

It's emc-tables@3 here because initially there were other tables that I
removed during preparation of the DT for upstream. Those tables were
untested and looked questionable to me.

> Anyway, looks like this has basically been like this since forever, so
> not much that can be done about it.
> 
> Again, the memory-controller node needs to be sorted differently. There
> are other occurrences of this throughout the file.

Please feel free to reorder it.