From mboxrd@z Thu Jan  1 00:00:00 1970
From: Soeren Moch <smoch@web.de>
Date: Wed, 26 Nov 2014 02:36:55 +0100
Subject: [U-Boot] [PATCH] dwc_ahsata.c: Add weak disable_sata_clock
In-Reply-To: <20141126002634.GB20704@bill-the-cat>
References: <1416952213-17623-1-git-send-email-trini@ti.com>
	<547507C1.9050909@web.de> <20141126002634.GB20704@bill-the-cat>
Message-ID: <54752EB7.9060108@web.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 26.11.2014 01:26, Tom Rini wrote:
> On Tue, Nov 25, 2014 at 11:50:41PM +0100, Soeren Moch wrote:
>> On 11/25/14 23:34, Soeren Moch wrote:
>>>> Signed-off-by: Tom Rini <trini@ti.com
>>>> <http://lists.denx.de/mailman/listinfo/u-boot>> --- 
>>>> drivers/block/dwc_ahsata.c |    5 +++++ 1 file changed, 5
>>>> insertions(+)
>>>> 
>>>> diff --git a/drivers/block/dwc_ahsata.c
>>>> b/drivers/block/dwc_ahsata.c index 9a2b547..e9d4283 100644 
>>>> --- a/drivers/block/dwc_ahsata.c +++
>>>> b/drivers/block/dwc_ahsata.c @@ -16,6 +16,7 @@ #include
>>>> <asm/errno.h> #include <asm/io.h> #include <linux/bitops.h> 
>>>> +#include <linux/compiler.h> #include <asm/arch/clock.h> 
>>>> #include <asm/arch/sys_proto.h> #include "dwc_ahsata.h" @@
>>>> -592,6 +593,10 @@ int init_sata(int dev) return 0; }
>>>> 
>>>> +__weak void  disable_sata_clock(void) +{ +} + int
>>>> reset_sata(int dev) { struct ahci_probe_ent *probe_ent =
>>> 
>>> Tom, Nikita,
>>> 
>>> instead of adding a weak function for architectures without
>>> 'disable_sata_clock', should we remove this call from
>>> reset_sata entirely?
>>> 
>>> 'reset_sata' is called repeatedly for several devices, but
>>> 'disable_sata_clock' has no such device parameter. Which clock
>>> should be disabled here? Makes not much sense for me.
>>> 
>>> BTW, there is an additional problem with 'reset_sata'. If sata
>>> support is configured into u-boot, but nobody has called 'sata
>>> init' before booting the kernel, I see a data abort exception
>>> on bootm. Tested on TBS2910 board (i.MX6Q-based).
> 
> I'm fine with reverting the original patch too, which sounds like
> the best case here.
> 

The original patch is part of a series which as a whole makes sense, I
think. Tomorrow I can provide a patch to fix this behavior - it is not
so easy to test patches currently, as u-boot-2015.01-rc2 is broken on
armhf.

  Soeren