On 28.07.22 10:15, Jarkko Sakkinen wrote: > 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? > Sure, that should not be too difficult to do. I will implement this for the next version. Regards, Lino
