Subject: Re: commit 9178ba294b6839eeff1a91bed95515d783f3ee6c an A-Eon Tabor Board

From: Julian Margetson <[email-masked]>
Date: Wed, 16 Mar 2016 07:56:24 -0400

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,
};