On Wed, Jul 27, 2022 at 02:16:56PM +0200, Lino Sanfilippo wrote: > > > On 11.07.22 04:50, Jarkko Sakkinen wrote: > > On Mon, Jul 04, 2022 at 07:45:12PM +0200, Lino Sanfilippo wrote: > >> > >> > >> On 01.07.22 01:29, Jarkko Sakkinen wrote: > >> > >>> > >>> I'm kind of thinking that should tpm_tis_data have a lock for its > >>> contents? > >> > >> Most of the tpm_tis_data structure elements are set once during init and > >> then never changed but only read. So no need for locking for these. The > >> exceptions I see are > >> > >> - flags > >> - locality_count > >> - locality > > > > I'd still go for single data struct lock, since this lock would > > be taken in every transmit flow. It makes the whole thing easier > > to maintain over time, and does not really affect scalability. > > > > This means switching to a complete new locking scheme which affects many > parts of the TIS core code. It is also not directly related to what this patch series > is about, namely activating the interrupts for TPM TIS. > > I suggest to first finish polishing this series especially since there have > only been minor issues in the last versions. Once the interrupts work we > still can think of implementing another lock handling in a follow up series. So what if you would use kref instead here? On surface this looks like ad-hoc kref but I could wrong too (as always). BR, Jarkko
