Re: [PATCH 4/4] Revert "drivers: convert sbd_duart.map_guard from atomic_t to refcount_t"

[Maciej W. Rozycki]

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