linux-kernel - Re: [PATCH v4 1/8] of: Add NVIDIA Tegra SATA controller binding

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]

Date:	Thu, 17 Jul 2014 08:51:15 +0200
From:	Hans de Goede <hdegoede@...hat.com>
To:	Thierry Reding <thierry.reding@...il.com>
CC:	Mikko Perttunen <mperttunen@...dia.com>, swarren@...dotorg.org,
	tj@...nel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-tegra@...r.kernel.org,
	linux-ide@...r.kernel.org
Subject: Re: [PATCH v4 1/8] of: Add NVIDIA Tegra SATA controller binding

Hi,

On 07/16/2014 09:51 PM, Thierry Reding wrote:
> On Wed, Jul 16, 2014 at 04:47:38PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 07/16/2014 03:13 PM, Thierry Reding wrote:
>>> On Wed, Jul 16, 2014 at 01:49:57PM +0200, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 07/16/2014 01:40 PM, Mikko Perttunen wrote:
>>>>> This patch adds device tree binding documentation for the SATA
>>>>> controller found on NVIDIA Tegra SoCs.
>>>>>
>>>>> Signed-off-by: Mikko Perttunen <mperttunen@...dia.com>
>>>>> ---
>>>>> v4: clarify mandatory clock order
>>>>
>>>> Thanks this and the new v4 of "ata: Add support for the Tegra124 SATA controller"
>>>> both look good to me. So these 2 + v3 for the rest of the series are:
>>>>
>>>> Acked-by: Hans de Goede <hdegoede@...hat.com>
>>>
>>> Like I said in my reply to PATCH v3 7/8, I think this mandatory clock
>>> order is a mistake.
>>
>> We've plenty of other dt bindings where things need to be specified in
>> a certain order, e.g. registers. So I don't really see what the problem
>> is here.
> 
> Like I said, the clock-names exists so that drivers can request a clock
> by name. Therefore the order in which they are listed doesn't matter.
> The only thing that matters is that the entries in clocks and
> clock-names match up.

Ok so I've been think about this, and about the unbalance I've noticed
between tegra_ahci_power_on which does everything DIY and tegra_ahci_power_off
which uses ahci_platform_disable_resources() in v3 and later.

Really only the "sata" clock needs special handling, so I think the following
solution is best:

1) Drop the clock ordering requirement and the clk enum

2) Make ahci_tegra.c do a devm_clk_get(dev, "sata"), so that it gets its
own handle to the sata-clk (store this in tegra_ahci_priv). no need to
get all the other clks which need no special handling

3) Start using ahci_platform_enable_resources() in tegra_ahci_power_on,
so it would look something like this:

static int tegra_ahci_power_on(struct ahci_host_priv *hpriv)
{
	struct tegra_ahci_priv *tegra = hpriv->plat_data;
	int ret;

	ret = regulator_bulk_enable(ARRAY_SIZE(tegra->supplies),
				    tegra->supplies);
	if (ret)
		return ret;

	ret = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_SATA,
						tegra->sata_clk,
						tegra->sata_rst);
	if (ret)
		goto disable_regulators;

	reset_control_deassert(tegra->sata_cold_rst);
	reset_control_deassert(tegra->sata_oob_rst);

	ret = ahci_platform_enable_resources(hpriv);
	if (ret)
		goto powergate_sequence_power_off;

	return 0;
...

This will make tegra_ahci_power_on and tegra_ahci_power_off symmetrical
which is something I always like to see in functions like this.

I realize that this changes the reset-deassert vs clock enabling ordering,
if this is an issue please add reset support to libahci-platform.c I believe
that is something which we will need to do soonish anyways (reset controllers
are popping up everywhere in newer SoCs).

This will nicely reduce the amount of code and also greatly simplify the error
return path of tegra_ahci_power_on.

This means that the sata_clk will get enabled twice, but that is harmless
as long as we disable it twice too. This means that we need to add an
extra disable to tegra_ahci_power_off because tegra_powergate_power_off
seems to not do this (unlike power-on, which is rather unsymmetrical
it would be nice to fix this).

Regards,

Hans
--
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/