On 3/30/2022 3:49 PM, Dmitry Osipenko wrote:
External email: Use caution opening links or attachments
On 3/30/22 12:03, Ashish Mhetre wrote:
On 3/30/2022 5:36 AM, Dmitry Osipenko wrote:
External email: Use caution opening links or attachments
On 3/16/22 12:25, Ashish Mhetre wrote:
Add new function 'get_int_channel' in tegra_mc_soc struture which is
implemented by tegra SOCs which support multiple MC channels. This
function returns the channel which should be used to get the information
of interrupts.
Remove static from tegra30_mc_handle_irq and use it as interrupt handler
for MC interrupts on tegra186, tegra194 and tegra234 to log the errors.
Add error specific MC status and address register bits and use them on
tegra186, tegra194 and tegra234.
Add error logging for generalized carveout interrupt on tegra186,
tegra194
and tegra234.
Add error logging for route sanity interrupt on tegra194 an tegra234.
Add register for higher bits of error address which is available on
tegra194 and tegra234.
Add a boolean variable 'has_addr_hi_reg' in tegra_mc_soc struture which
will be true if soc has register for higher bits of memory controller
error address. Set it true for tegra194 and tegra234.
Signed-off-by: Ashish Mhetre <amhetre@xxxxxxxxxx>
Reported-by: kernel test robot <lkp@xxxxxxxxx>
Reported-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
Reported what? You should add this tag only if patch addresses reported
problem. This patch doesn't address anything, hence the tag is
inappropriate, you should remove it.
Okay, smatch warning was reported on v4 of this patch which is fixed in
v5. Then I understand that we don't need to add Reported-by if we fix
bug in subsequent versions, right?
Right, if the report was made to the in-progress patch, then you
shouldn't add the tag.
If report was made to the patch that was already merged, then you should
create a new patch that fixes the reported problem and add the
reported-by to this patch.
Got it, thanks for the explanation. I'll remove tag from next version.
