Re: commit 9178ba294b6839eeff1a91bed95515d783f3ee6c an A-Eon Tabor Board

[Julian Margetson <runaway@candw.ms>]

[-- Attachment #1: Type: text/plain, Size: 2691 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 8337 bytes --]