From: Jakub Kicinski <kubakici@wp.pl>
To: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] mt7601u: make write with mask access atomic
Date: Fri, 16 Feb 2018 13:08:10 -0800 [thread overview]
Message-ID: <20180216130810.7f40da40@cakuba.netronome.com> (raw)
In-Reply-To: <20180216090648.GA2580@localhost.localdomain>
On Fri, 16 Feb 2018 10:06:49 +0100, Lorenzo Bianconi wrote:
> > Hm.. There should be no path in the driver where that could cause
> > problems AFAIR. We have reg_atomic_mutex and hw_atomic_mutex to
> > protect from concurrent access to the HW where they are possible.
> > RMW operations are non-atomic by definition, it's supposed to work
> > like PCIe register accesses would - 32bit reads/writes are atomic,
> > but RMW is not.
>
> Yes, RMW accesses are non-atomic by default but since vendor_req_mutex mutex
> is already there (and grabbed for RMW operations), why not use it to make write
> with mask access atomic without adding complexity? Moreover it would be a
> micro-optimisation since vendor_req_mutex would be grabbed just once instead of
> twice
>
> >
> > So I'm not sure what to do with this patch. Doesn't seem necessary...
>
> It is just a trivial rework of locking in usb read/write accesses, not
> mandatory, so if you prefer we can just drop it
You make good points :) Could you please respin stating clearly in the
commit message that this is not a bug fix, but a micro-optimization and
may be useful in the future?
next prev parent reply other threads:[~2018-02-16 21:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1518734856.git.lorenzo.bianconi@redhat.com>
2018-02-15 22:59 ` [PATCH] mt7601u: make write with mask access atomic Lorenzo Bianconi
2018-02-15 23:14 ` Jakub Kicinski
2018-02-16 0:02 ` Lorenzo Bianconi
2018-02-16 0:35 ` Jakub Kicinski
2018-02-16 9:06 ` Lorenzo Bianconi
2018-02-16 21:08 ` Jakub Kicinski [this message]
2018-02-28 14:51 ` Kalle Valo
2018-02-28 15:04 ` Lorenzo Bianconi
2018-02-28 15:07 ` Kalle Valo
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=20180216130810.7f40da40@cakuba.netronome.com \
--to=kubakici@wp.pl \
--cc=linux-wireless@vger.kernel.org \
--cc=lorenzo.bianconi@redhat.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 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).