From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Jiri Slaby <jirislaby@kernel.org>,
Elena Reshetova <elena.reshetova@intel.com>,
David Windsor <dwindsor@gmail.com>, Kees Cook <kees@kernel.org>,
Hans Liljestrand <ishkamiel@gmail.com>,
linux-mips@vger.kernel.org, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] Revert "drivers: convert sbd_duart.map_guard from atomic_t to refcount_t"
Date: Mon, 27 Apr 2026 21:06:56 +0100 (BST) [thread overview]
Message-ID: <alpine.DEB.2.21.2604272057250.28583@angie.orcam.me.uk> (raw)
In-Reply-To: <2026042737-siamese-cod-84c5@gregkh>
On Mon, 27 Apr 2026, Greg Kroah-Hartman wrote:
> > > How about fix this up to work properly with a refcount? having "open
> > > coded" atomic variables like this is ripe for problems, like it seems
> > > this driver is abusing.
> >
> > Clearly refcount has odd semantics for this use case, as the failed
> > attempt to "fix" this code has shown.
> >
> > The natural values for `map_guard' are 0 and 1 (FALSE and TRUE), for the
> > resource not taken and taken respectively, however refcount code complains
> > about this arrangement as indicated by the report quoted.
> >
> > I suppose I can bend backwards and adopt other values, which I'll have to
> > figure out from the API somehow, but it's not clear to me how it would
> > cause less confusion than original straightforward code, the whole point
> > of which is to prevent the resource from being requested again for the
> > second port in a DUART.
> >
> > Or I could use an ordinary variable, possibly of the `bool' type, guarded
> > by a spinlock, but that would be even more of an overkill IMO.
>
> No, that would be best because using an atomic is the same end result,
> but it confuses us humans who are the ones responsible for maintaining
> the code over time.
Right, it's missing a MAINTAINERS entry; I'll add one with the respin as
I wrote this stuff anyway and still care the most I believe. And having
thought a little about it at a bus stop I realised I got confused too, so
it may have to be a counter after all. I'll see what fits best, but I'm
currently away from this hardware (which is not at my lab) until mid May,
so it'll have to wait.
Maciej
prev parent reply other threads:[~2026-04-27 20:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-13 3:28 [PATCH 0/4] MIPS: SiByte: Fix serial device regressions Maciej W. Rozycki
2026-04-13 3:28 ` [PATCH 1/4] MIPS: SiByte: Fix console message clobbering at channel resets Maciej W. Rozycki
2026-04-13 3:28 ` [PATCH 2/4] MIPS: SiByte: Fix bootconsole handover lockup Maciej W. Rozycki
2026-04-13 3:28 ` [PATCH 3/4] MIPS: SiByte: Convert to use a platform device Maciej W. Rozycki
2026-04-13 3:28 ` [PATCH 4/4] Revert "drivers: convert sbd_duart.map_guard from atomic_t to refcount_t" Maciej W. Rozycki
2026-04-26 20:45 ` Greg Kroah-Hartman
2026-04-27 14:13 ` Maciej W. Rozycki
2026-04-27 16:31 ` Greg Kroah-Hartman
2026-04-27 20:06 ` Maciej W. Rozycki [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=alpine.DEB.2.21.2604272057250.28583@angie.orcam.me.uk \
--to=macro@orcam.me.uk \
--cc=dwindsor@gmail.com \
--cc=elena.reshetova@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=ishkamiel@gmail.com \
--cc=jirislaby@kernel.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=tsbogend@alpha.franken.de \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).