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.
