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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ba6d4378-b646-4514-3a45-4b6c951fbb9c@kalrayinc.com>
Date:   Wed, 20 Sep 2023 15:27:10 +0200
From:   Yann Sionneau <ysionneau@...rayinc.com>
To:     Wolfram Sang <wsa@...nel.org>,
        Serge Semin <fancer.lancer@...il.com>,
        Jan Bottorff <janb@...amperecomputing.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Yann Sionneau <yann@...nneau.net>,
        Will Deacon <will@...nel.org>,
        Jarkko Nikula <jarkko.nikula@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Jan Dabros <jsd@...ihalf.com>,
        Andi Shyti <andi.shyti@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] i2c: designware: Fix corrupted memory seen in the
 ISR

Hi,

On 20/09/2023 11:08, Wolfram Sang wrote:
>> same thread." [1] Thus I'd suggest the next fix for the problem:
>>
>> --- a/drivers/i2c/busses/i2c-designware-common.c
>> +++ b/drivers/i2c/busses/i2c-designware-common.c
>> @@ -72,7 +72,10 @@ static int dw_reg_write(void *context, unsigned int reg, unsigned int val)
>>   {
>>   	struct dw_i2c_dev *dev = context;
>>   
>> -	writel_relaxed(val, dev->base + reg);
>> +	if (reg == DW_IC_INTR_MASK)
>> +		writel(val, dev->base + reg);
>> +	else
>> +		writel_relaxed(val, dev->base + reg);
>>   
>>   	return 0;
>>   }
>>
>> (and similar changes for dw_reg_write_swab() and dw_reg_write_word().)
>>
>> What do you think?
> To me, this looks reasonable and much more what I would have expected as
> a result (from a high level point of view). Let's hope it works. I am
> optimistic, though...
>
It works if we make sure all the other register accesses to the 
designware i2c IP can't generate IRQ.

Meaning that all register accesses that can trigger an IRQ are enclosed 
in between a call to i2c_dw_disable_int() and a call to 
regmap_write(dev->map, DW_IC_INTR_MASK, DW_IC_INTR_MASTER_MASK); or 
equivalent.

It seems to be the case, I'm not sure what's the best way to make sure 
it will stay that way.

Moreover, maybe writes to IC_ENABLE register should also use the 
non-relaxed writel() version?

Since one could do something like:

[ IP is currently disabled ]

1/ enable interrupts in DW_IC_INTR_MASK

2/ update some variable in dev-> structure in DDR

3/ enable the device by writing to IC_ENABLE, thus triggering for 
instance the TX_FIFO_EMPTY irq.

Regards,

-- 

Yann





Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ