linux-kernel - Re: [PATCH v5 4/4] memory: tegra: Add MC error logging support for Tegra264

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] [day] [month] [year] [list]

Message-ID: <f1857497-6b4d-4387-a593-dfa5750c59e8@nvidia.com>
Date: Wed, 7 Jan 2026 12:57:36 +0000
From: Jon Hunter <jonathanh@...dia.com>
To: Ketan Patil <ketanp@...dia.com>, krzk@...nel.org, thierry.reding@...il.com
Cc: linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH v5 4/4] memory: tegra: Add MC error logging support for
 Tegra264


On 07/01/2026 12:47, Jon Hunter wrote:

...

>> @@ -283,6 +329,359 @@ static int tegra264_mc_icc_get_init_bw(struct 
>> icc_node *node, u32 *avg, u32 *pea
>>       return 0;
>>   }
>> +static void mcf_log_fault(struct tegra_mc *mc, u32 channel, unsigned 
>> long mcf_ch_intstatus)
>> +{
>> +    unsigned int bit;
>> +
>> +    for_each_set_bit(bit, &mcf_ch_intstatus, 32) {
>> +        const char *error = tegra264_mc_status_names[bit] ?: "unknown";
>> +        u32 intmask = BIT(bit);
>> +        u32 status_reg, status1_reg = 0, addr_reg, addr_hi_reg = 0;
>> +        u32 addr_val, value, client_id, i, addr_hi_shift = 0, 
>> addr_hi_mask = 0, status1;
>> +        const char *direction, *secure;
>> +        const char *client = "unknown", *desc = "NA";
>> +        phys_addr_t addr = 0;
>> +        bool is_gsc = false, err_type_valid = false, 
>> err_rt_type_valid = false;
>> +        u8 type;
>> +        u32 mc_rw_bit = MC_ERR_STATUS_RW, mc_sec_bit = 
>> MC_ERR_STATUS_SECURITY;
> 
> There are a lot of variables here. Do we really need all these? Surely 
> we can get rid of mc_rw_bit and mc_sec_bit and use the definitions 
> directly? And ...

I see that mc_rw_bit and mc_sec_bit may be updated and so we need these. 
However, we should try to reduce the number of variables to only what is 
really needed.

Jon

-- 
nvpublic