linux-kernel - Re: [Patch v5 2/4] memory: tegra: Add MC error logging on tegra186 onward

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b3527362-8cc4-3435-7d06-0df57839ef82@nvidia.com>
Date:   Tue, 22 Mar 2022 22:18:51 +0530
From:   Ashish Mhetre <amhetre@...dia.com>
To:     Dmitry Osipenko <digetx@...il.com>,
        krzysztof.kozlowski@...onical.com, robh+dt@...nel.org,
        thierry.reding@...il.com, jonathanh@...dia.com,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-tegra@...r.kernel.org
Cc:     vdumpa@...dia.com, Snikam@...dia.com
Subject: Re: [Patch v5 2/4] memory: tegra: Add MC error logging on tegra186
 onward



On 3/19/2022 9:20 PM, Dmitry Osipenko wrote:
> External email: Use caution opening links or attachments
> 
> 
> 16.03.2022 12:25, Ashish Mhetre пишет:
>> +irqreturn_t tegra30_mc_handle_irq(int irq, void *data)
>>   {
>>        struct tegra_mc *mc = data;
>>        unsigned long status;
>> +     bool mc_has_channels;
>>        unsigned int bit;
>> +     int channel;
> 
> unsigned int
> 
Okay, I will update in next version.

>> +     mc_has_channels = mc->soc->num_channels && mc->soc->get_int_channel;
>> +     if (mc_has_channels) {
>> +             int err;
>> +
>> +             err = mc->soc->get_int_channel(mc, &channel);
>> +             if (err < 0)
>> +                     return IRQ_NONE;
>> +
>> +             /* mask all interrupts to avoid flooding */
>> +             status = mc_ch_readl(mc, channel, MC_INTSTATUS) & mc->soc->intmask;
>> +     } else {
>> +             status = mc_readl(mc, MC_INTSTATUS) & mc->soc->intmask;
>> +     }
> 
> So if mc_has_channels=false, while it should be true, then you're going
> to handle interrupt incorrectly?

I am not able to understand the case where this can happen?
num_channels and get_int_channels are both getting defined on T186
onwards where mc_has_channels is expected to be true.
Do you mean to say that we need to add more chip specific checks
in case of mc_has_channels is false?