All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
To: Jarkko Sakkinen <jarkko@kernel.org>
Cc: peterhuewe@gmx.de, jgg@ziepe.ca, stefanb@linux.vnet.ibm.com,
	linux@mniewoehner.de, linux-integrity@vger.kernel.org,
	linux-kernel@vger.kernel.org, lukas@wunner.de,
	p.rosenberger@kunbus.com,
	Lino Sanfilippo <l.sanfilippo@kunbus.com>
Subject: Re: [PATCH v4 1/6] tpm, tpm_tis_spi: Request threaded irq
Date: Mon, 16 May 2022 21:52:05 +0200	[thread overview]
Message-ID: <1b306d56-c6b3-e51f-1d63-2f6725fa7557@gmx.de> (raw)
In-Reply-To: <Yn6esMyUl+QhECq+@kernel.org>

Hi,

On 13.05.22 at 20:08, Jarkko Sakkinen wrote:
> On Wed, May 11, 2022 at 09:18:39PM +0200, Lino Sanfilippo wrote:
>> Hi,
>>
>> On 11.05.22 at 13:22, Jarkko Sakkinen wrote:
>>> On Mon, May 09, 2022 at 10:05:54AM +0200, Lino Sanfilippo wrote:
>>>> From: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>>>
>>>> Interrupt handling at least includes reading and writing the interrupt
>>>> status register within the interrupt routine. Since accesses over the SPI
>>>> bus are synchronized by a mutex, request a threaded interrupt handler to
>>>> ensure a sleepable context during interrupt processing.
>>>>
>>>> Fixes: 1a339b658d9d ("tpm_tis_spi: Pass the SPI IRQ down to the driver")
>>>> Signed-off-by: Lino Sanfilippo <l.sanfilippo@kunbus.com>
>>>
>>> When you state that it needs a sleepable context, you should bring a
>>> context why it needs it. This not to disregard the code change overally but
>>> you cannot make even the most obvious claim without backing data.
>>>
>>
>> so what kind of backing data do you have in mind? Would it help to emphasize more
>> that the irq handler is running in hard irq context in the current code and thus
>> must not access registers over SPI since SPI uses a mutex (I consider it as basic
>> knowledge that a mutex must not be taken in hard irq context)?
>
> There's zero mention about specific lock you are talking about. Providing
> the basic knowledge what you are trying to do is the whole point of the
> commit message in the first place. I'd presume this patch is related to the
> use bus_lock_mutex but it is fully ingored here.
>

Ok, understood. I will amend the commit message to make more clear that
reading and writing registers from the interrupt handler results in
a call to tpm_tis_spi_transfer() which uses the bus_lock_mutex of the
spi device and thus requires a sleepable context.


Regards,
Lino



> BR, Jarkko
>


  reply	other threads:[~2022-05-16 20:20 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-09  8:05 [PATCH v4 0/6] TPM irq fixes Lino Sanfilippo
2022-05-09  8:05 ` [PATCH v4 1/6] tpm, tpm_tis_spi: Request threaded irq Lino Sanfilippo
2022-05-11 11:22   ` Jarkko Sakkinen
2022-05-11 19:18     ` Lino Sanfilippo
2022-05-13 18:08       ` Jarkko Sakkinen
2022-05-16 19:52         ` Lino Sanfilippo [this message]
2022-05-17 18:23           ` Jarkko Sakkinen
2022-05-09  8:05 ` [PATCH v4 2/6] tpm, tpm_tis: Claim and release locality only once Lino Sanfilippo
2022-05-11 11:27   ` Jarkko Sakkinen
2022-05-11 19:29     ` Lino Sanfilippo
2022-05-13 17:59       ` Jarkko Sakkinen
2022-05-16 20:23         ` Lino Sanfilippo
2022-05-09  8:05 ` [PATCH v4 3/6] tpm, tpm_tis: enable irq test Lino Sanfilippo
2022-05-09  8:05 ` [PATCH v4 4/6] tpm, tpm_tis: avoid CPU cache incoherency in " Lino Sanfilippo
2022-05-11 15:06   ` Jarkko Sakkinen
2022-05-11 19:35     ` Lino Sanfilippo
2022-05-09  8:05 ` [PATCH v4 5/6] tpm, tpm_tis: Move irq test from tpm_tis_send() to tpm_tis_probe_irq_single() Lino Sanfilippo
2022-05-11 15:09   ` Jarkko Sakkinen
2022-05-11 19:56     ` Lino Sanfilippo
2022-05-16 17:51       ` Jarkko Sakkinen
2022-05-16 20:25         ` Lino Sanfilippo
2022-05-17 18:19           ` Michael Niewöhner
2022-05-18  1:26             ` Jarkko Sakkinen
2022-05-18 16:08               ` Michael Niewöhner
2022-05-09  8:05 ` [PATCH v4 6/6] tpm, tpm_tis: Only enable supported IRQs Lino Sanfilippo
2022-05-11 15:08   ` Jarkko Sakkinen
2022-05-11 19:58     ` Lino Sanfilippo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1b306d56-c6b3-e51f-1d63-2f6725fa7557@gmx.de \
    --to=linosanfilippo@gmx.de \
    --cc=jarkko@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=l.sanfilippo@kunbus.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@mniewoehner.de \
    --cc=lukas@wunner.de \
    --cc=p.rosenberger@kunbus.com \
    --cc=peterhuewe@gmx.de \
    --cc=stefanb@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.