linux-kernel - Re: [PATCH v2 17/22] memory: tegra30-emc: Register as interconnect provider

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: <8d072775-aec8-5a55-8fd7-7166e2a34c95@gmail.com>
Date:   Mon, 13 Apr 2020 18:18:01 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Georgi Djakov <georgi.djakov@...aro.org>,
        Thierry Reding <thierry.reding@...il.com>
Cc:     Jonathan Hunter <jonathanh@...dia.com>,
        Artur Świgoń <a.swigon@...sung.com>,
        Rob Herring <robh+dt@...nel.org>, linux-tegra@...r.kernel.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 17/22] memory: tegra30-emc: Register as interconnect
 provider

13.04.2020 15:44, Georgi Djakov пишет:
...
> All the above seems like a duplicate of what we already have in the previous
> patch for tegra20-emc. Can we have a single driver for both? Maybe extract the
> above as a separate interconnect provider driver.

Perhaps we could do it later on, once the work on the drivers will
settle down. I think it should be okay to have some minor duplication
for now, we already have some other small things duplicated in these
drivers.

>>  static int tegra_emc_probe(struct platform_device *pdev)
>>  {
>>  	struct platform_device *mc;
>> @@ -1344,6 +1452,13 @@ static int tegra_emc_probe(struct platform_device *pdev)
>>  	platform_set_drvdata(pdev, emc);
>>  	tegra_emc_debugfs_init(emc);
>>  
>> +	if (IS_ENABLED(CONFIG_INTERCONNECT)) {
>> +		err = tegra_emc_interconnect_init(emc);
> 
> How about registering a platform device that will use the same driver to handle
> the interconnect functionality for both tegra20 and tegra30?

It should be possible. But it also should be possible to make all these
drivers modular, which I'm going to try out.