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 at 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
