Are you using a device tree? If yes, make sure there is an entry for this device.
>From your snippet of code, there appears to be a match entry in of_match_table?
Steve
> On Nov 17, 2018, at 6:22 PM, Tracy Smith <tlsmith3777@xxxxxxxxx> 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@xxxxxxxxx> 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.
>>>
>>> I have set CONFIG_EDAC_DEBUG and set edac_debug_level to 4, but I
>>> don’t see any debug messages other than printk()s that I add to
>>> fsl_ddr_mc_init() in layerscape_edac.c. No debug messages appear in
>>> any logs from fsl_ddr_edac.c.
>>>
>>> 1. How can I enable debug information? Is debugfs required to print
>>> the debug messages for the edac_debug_level and CONFIG_EDAC_DEBUG in
>>> the 4.1.35-rt41 kernel for drivers/edac?
>>
>> No, just slap printks before every return statement, like:
>>
>> if (!devres_open_group(&op->dev, fsl_mc_err_probe, GFP_KERNEL)) {
>> pr_err("%s: Error devres_open_group()\n", __func__);
>> return -ENOMEM;
>> }
>>
>> so that you can get closer to the place where it fails.
>>
>>> 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:
>>
>> 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__);
>>
>>
>>> 3. I don’t see any interrupts, so why would there not be an edac
>>> interrupt in /proc/inturrupts?
>>
>> Probably because it doesn't reach the point where it registers an IRQ
>> handler...
>>
>>> Do I need to inject an error before seeing an edac interrupt in
>>> /proc/interrupts?
>>
>> You should, AFAICT, if it loads and registers stuff properly.
>>
>>> lsmod
>>> module: layerscape_edac_mod 12594 0
>>>
>>> 4. To inject an error I can use the fsl_mc_inject …. routines in
>>> fsl_ddr_edac.c and write to the registers. But is there a utility that
>>> already uses these routines that can be used to inject an error
>>> (FSL_MC_ECC_ERR_INJECT, FSL_MC_DATA_ERR_INJECT_LO,
>>
>> You should be able to simply write to *sysfs*. Somewhere under
>> /sys/devices/system/edac/...
>>
>> fsl_mc_inject_data_{lo,hi}_store simply writes the low and high inject
>> register.
>>
>> Btw, looking at it, York, this whole injection functionality needs to
>> be behind CONFIG_EDAC_DEBUG because a production driver shouldn't have
>> injection capability.
>>
>> Hmmm.
>>
>> --
>> Regards/Gruss,
>> Boris.
>>
>> Good mailing practices for 400: avoid top-posting and trim the reply.
>
>
>
> --
> Confidentiality notice: This e-mail message, including any
> attachments, may contain legally privileged and/or confidential
> information. If you are not the intended recipient(s), please
> immediately notify the sender and delete this e-mail message.
