Re: FW: edac driver initialization, interrupt, & debug

[York Sun <york.sun@nxp.com>]

On 11/17/18 3:22 PM, Tracy Smith wrote:
> Thank you Boris for the information.  It is helpful.
> 
>>> 2. The default EDAC_OPSTATE_INT in fsl_ddr_mc_init() and the
>>> platform_driver_register() is successful. But I don’t see any printk()
>>> messages in fsl_mc_err_probe() within fsl_ddr_edac.c. No errors appear
>>> in any /var/log/*.
> 
>> Yeah, see if it even gets called at all:
> 
> I did a grep on /var/log/* and don't see any printk's from
> fsl_mc_err_probe(). So, it's not being called.
> 
> 1) What would cause the probe function not to be called?
> 
> 2) Were changes made in how .probe functions were called between
> different kernel releases of the edac?
> 
> 3) How should I go about root causing the reason for the .probe to
> fail since I may have to backport any changes made?
> 
> 4) Possibly a patch exists for .probe changes after 4.1.35-rt41?
> 
> static struct platform_driver fsl_ddr_mc_err_driver = {
> 
> .probe = fsl_mc_err_probe,
> .remove = fsl_mc_err_remove,
> .driver = {
>               .name = "fsl_ddr_mc_err",
>               .of_match_table = fsl_ddr_mc_err_of_match,
>     },
> }l;
> 
> int fsl_mc_err_probe(struct platform_device *op)
> 
> {
>  struct mem_ctl_info *mci;
>  struct edac_mc_layer layers[2];
>  struct fsl_mc_pdata *pdata;
>  struct resource r;
>  u32 sdram_ctl;
>  int res;
> 
> pr_err("%s: entry\n", __func__);
> printk("entered fsl_mc_err_probe!\n");
> 
> Any assistance greatly appreciated.
> 
> 
> On Sat, Nov 17, 2018 at 8:05 AM Borislav Petkov <bp@alien8.de> wrote:
>>
>> + York.
>>
>> On Fri, Nov 16, 2018 at 11:07:50AM -0600, Tracy Smith wrote:
>>> I’m attempting to insmod/modprobe the layerscape_edac_mod.ko driver.
>>> It seems the driver enters layerscape_edac.c fsl_ddr_mc_init() and
>>> completes successfully. But there is no EDAC boot messages and no
>>> /proc/interrupts entry for the EDAC. I’m backporting the EDAC from the
>>> LSDK to the SDK 2.0.

Tracy,

You said you were backporting to an older release. Please double check
your device tree _after_ Linux reaches prompt. You can find it at
/proc/device-tree. You can also check the device tree in U-Boot using
bootm command step-by-step, after the fixup.

As long as you have correct "compatible", the probe function should be
called. It may quit if ECC is not detected, or not register interrupt if
not found in device tree.

York
--
To unsubscribe from this list: send the line "unsubscribe backports" in