commit 9178ba294b6839eeff1a91bed95515d783f3ee6c an A-Eon Tabor Board
Julian Margetson
runaway at candw.ms
Wed Mar 16 22:56:24 AEDT 2016
On 2/3/2016 6:59 PM, Alexander Graf wrote:
>
>
> On 02/03/2016 11:54 PM, Julian Margetson wrote:
>> On 2/3/2016 6:20 PM, Alexander Graf wrote:
>>>
>>>
>>> On 02/03/2016 11:15 PM, Julian Margetson wrote:
>>>> On 2/3/2016 4:43 PM, Alexander Graf wrote:
>>>>>
>>>>>
>>>>> On 02/03/2016 10:33 AM, Julian Margetson wrote:
>>>>>> Resending as it was attached to and old thread relating to a
>>>>>> different motherboard.
>>>>>>
>>>>>> On 2/2/2016 9:54 AM, Julian Margetson wrote:
>>>>>>>
>>>>>>> Commit 9178ba294b6839eeff1a91bed95515d783f3ee6c prevents
>>>>>>> building of kernel 4.1 branch on A-Eon Tabor Board.
>>>>>>>
>>>>>>> CC arch/powerpc/math-emu/fsqrt.o
>>>>>>> arch/powerpc/platforms/85xx/tabor.c:194:2: error: unknown field
>>>>>>> ‘power_off’ specified in initializer
>>>>>
>>>>> I can't seem to find that file in Linux upstream?
>>>>>
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>>
>>>>
>>>> It may have been discontinued as the patches used were maintained
>>>> along with patches for the (Varisys) A-Eon Cyrus board
>>>> which is officially supported from kernel 4.4.
>>>>
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c383ee84e1d575b09d167185d15df24bde25eb15
>>>>
>>>
>>> I don't quite understand how an internal API change in Linux
>>> breaking random external patches is a bug? Either your code is
>>> upstream or it can break on every git commit done upstream.
>>>
>>>
>>> Alex
>>>
>>>
>>>
>>
>> Sorry I am relatively new at this.
>> If I manage to pinpoint a problem on my powerpc machines I report it
>> . Most of them so far have indeed been bugs.
>> The random external patches were done by person with far greater
>> competence than me who are no longer in the picture.
>> Any guidance would be greatly appreciated.
>
> I think the most important step really is to upstream board support,
> otherwise things will continue to fall apart for sure.
>
> As for the exact breakage you saw, just remove the line and put a line
> like
>
> pm_power_off = tabor_power_off;
>
> in your board probe function in tabor.c.
>
>
> Alex
>
>
>
Could not get it to work with the
pm_power_off = tabor_power_off;
so resorted to the option below and it builds and boots (Tested Kernel
4.5.0).
shuts down but no power off.
Can live with that for now.
Thanks for your help .
Regards
Julian
define_machine(tabor) {
.name= "Tabor",
.probe= tabor_probe,
.setup_arch= tabor_setup_arch,
.init_IRQ= tabor_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus= fsl_pcibios_fixup_bus,
.pcibios_fixup_phb= fsl_pcibios_fixup_phb,
#endif
.get_irq= mpic_get_irq,
.restart= fsl_rstcr_restart,
.calibrate_decr= generic_calibrate_decr,
.progress= udbg_progress,
};
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20160316/f151897c/attachment.html>
More information about the Linuxppc-dev
mailing list