From: Wolfram Sang <wsa@the-dreams.de>
To: "Adamski, Krzysztof (Nokia - PL/Wroclaw)" <krzysztof.adamski@nokia.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
"Sverdlin,
Alexander (Nokia - DE/Ulm)" <alexander.sverdlin@nokia.com>
Subject: Re: [PATCH] i2c-axxia: support slave mode
Date: Wed, 7 Aug 2019 17:19:44 +0200 [thread overview]
Message-ID: <20190807151943.GA2338@kunai> (raw)
In-Reply-To: <20190807070926.GB17104@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
Hi Krzysztof,
> Good point. I'll remove those verbose messages and maybe leave one or
> two debug messages with just a summary of the status which will
> hopefully be a good compromise. Will that be ok?
Very likely :)
> BTW, I have added this synchronize_irq() in unreg_slave callback just to
> make sure it is save to set idev->slave to NULL already. Most of the
> controllers do not have such a guard and I'm wondering why that wouldn't
> be a problem for them. Like the i2c-rcar.c - isn't there a small race
> condition if some slave interrupt triggers just before ICSIER is cleared
> and somehow does not finish before priv->slave is set to NULL? This is
> the situation I was afraid of and tried to solve by using this
> synchronize_irq().
You have an important point there. unreg_slave is protected by the
adapter lock but this won't help if another master is requesting
something, thus, causing interrupts.
Phew, nearly all slave implementation need to fix this!
Thanks a lot,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2019-08-07 15:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-01 13:21 [PATCH] i2c-axxia: support slave mode Adamski, Krzysztof (Nokia - PL/Wroclaw)
2019-08-06 20:51 ` Wolfram Sang
2019-08-07 7:09 ` Adamski, Krzysztof (Nokia - PL/Wroclaw)
2019-08-07 15:19 ` Wolfram Sang [this message]
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=20190807151943.GA2338@kunai \
--to=wsa@the-dreams.de \
--cc=alexander.sverdlin@nokia.com \
--cc=krzysztof.adamski@nokia.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.