linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: linux-kernel@vger.kernel.org,
	Andreas Noever <andreas.noever@gmail.com>,
	Michael Jamet <michael.jamet@intel.com>,
	Yehezkel Bernat <YehezkelShB@gmail.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>,
	Mario.Limonciello@dell.com,
	Anthony Wong <anthony.wong@canonical.com>,
	Rajmohan Mani <rajmohan.mani@intel.com>,
	Raanan Avargil <raanan.avargil@intel.com>,
	David Laight <David.Laight@aculab.com>,
	linux-acpi@vger.kernel.org
Subject: Re: [PATCH v2 7/8] thunderbolt: Add support for Intel Ice Lake
Date: Tue, 13 Aug 2019 19:49:30 +0300	[thread overview]
Message-ID: <20190813164930.GA18281@lahna.fi.intel.com> (raw)
In-Reply-To: <20190813161038.tip2u2z22xqnmfjl@wunner.de>

On Tue, Aug 13, 2019 at 06:10:38PM +0200, Lukas Wunner wrote:
> On Mon, Aug 12, 2019 at 03:38:46PM +0300, Mika Westerberg wrote:
> > +static void icm_veto_begin(struct tb *tb)
> > +{
> > +	struct icm *icm = tb_priv(tb);
> > +
> > +	if (!icm->veto) {
> > +		icm->veto = true;
> > +		/* Keep the domain powered while veto is in effect */
> > +		pm_runtime_get(&tb->dev);
> > +	}
> > +}
> 
> Hm, don't you need memory barriers when accessing icm->veto?

AFAICT it does not need them, it is protected under mutex where there
can be concurrency.

> If so, I'd suggest:
> 
> 	/* Keep the domain powered while veto is in effect */
> 	if (cmpxchg(&icm->veto, false, true))
> 		pm_runtime_get(&tb->dev);
> 
> You'll have to declare icm->veto unsigned int instead of bool
> because thunderbolt.ko is compiled if CONFIG_COMPILE_TEST is
> enabled and there are arches which do not support cmpxchg for
> a size of 1 byte.
> 
> The other bools in struct icm should likewise be unsigned int
> per Linus' dictum:
> https://lkml.org/lkml/2017/11/21/384

Yeah, it probably wastes some space but I like them because IMHO they
are more readable than bitfields. We have a bunch of other bools in the
driver structures so if we are going to convert struct icm we should do
the same for others to keep things consistent. Probably should be a
separate cleanup patch.

> > --- a/drivers/thunderbolt/nhi.c
> > +++ b/drivers/thunderbolt/nhi.c
> > +/* Ice Lake specific NHI operations */
> > +
> 
> Again, can't this be moved to a separate file for maintainability?

Sure.

  reply	other threads:[~2019-08-13 16:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-12 12:38 [PATCH v2 0/8] thunderbolt: Intel Ice Lake support Mika Westerberg
2019-08-12 12:38 ` [PATCH v2 1/8] thunderbolt: Correct path indices for PCIe tunnel Mika Westerberg
2019-08-12 12:38 ` [PATCH v2 2/8] thunderbolt: Move NVM upgrade support flag to struct icm Mika Westerberg
2019-08-12 12:38 ` [PATCH v2 3/8] thunderbolt: Use 32-bit writes when writing ring producer/consumer Mika Westerberg
2019-08-12 12:38 ` [PATCH v2 4/8] thunderbolt: Do not fail adding switch if some port is not implemented Mika Westerberg
2019-08-12 12:38 ` [PATCH v2 5/8] thunderbolt: Hide switch attributes that are not set Mika Westerberg
2019-08-12 12:38 ` [PATCH v2 6/8] thunderbolt: Expose active parts of NVM even if upgrade is not supported Mika Westerberg
2019-08-12 12:38 ` [PATCH v2 7/8] thunderbolt: Add support for Intel Ice Lake Mika Westerberg
2019-08-13 16:10   ` Lukas Wunner
2019-08-13 16:49     ` Mika Westerberg [this message]
2019-08-13 17:01       ` Mika Westerberg
2019-08-12 12:38 ` [PATCH v2 8/8] ACPI / property: Add two new Thunderbolt property GUIDs to the list Mika Westerberg
2019-08-12 21:34   ` Rafael J. Wysocki

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=20190813164930.GA18281@lahna.fi.intel.com \
    --to=mika.westerberg@linux.intel.com \
    --cc=David.Laight@aculab.com \
    --cc=Mario.Limonciello@dell.com \
    --cc=YehezkelShB@gmail.com \
    --cc=andreas.noever@gmail.com \
    --cc=anthony.wong@canonical.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=michael.jamet@intel.com \
    --cc=raanan.avargil@intel.com \
    --cc=rajmohan.mani@intel.com \
    --cc=rjw@rjwysocki.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).