Re: [PATCH v5 08/10] iio: adc: ad_sigma_delta: Check for previous ready signals

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 3, 2024 at 8:47 PM Uwe Kleine-König
<u.kleine-koenig@xxxxxxxxxxxx> wrote:
> On Tue, Dec 03, 2024 at 07:47:53PM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 3, 2024 at 6:16 PM Uwe Kleine-König
> > <u.kleine-koenig@xxxxxxxxxxxx> wrote:
> > > On Tue, Dec 03, 2024 at 03:10:30PM +0200, Andy Shevchenko wrote:
> > > > On Tue, Dec 3, 2024 at 1:01 PM Uwe Kleine-König
> > > > <u.kleine-koenig@xxxxxxxxxxxx> wrote:
> > > > >
> > > > > It can happen if a previous conversion was aborted the ADC pulls down
> > > > > the ̅R̅D̅Y line but the event wasn't handled before. In that case enabling
> > > >
> > > > Interesting use of Unicode, but I suggest to avoid it when it can be
> > > > avoided, i.e.
> > > > using the notation of #RDY_N might be appropriate as that is how
> > > > usually the HW people refer to the active low signals.
> > >
> > > Usage of ̅R̅D̅Y has the advantage to match the reference manual and data
> > > sheet. So I tend to keep it.
> >
> > Not sure it's strictly the same. The above has two dashes on top
> > (actually misaligned a bit) of two letters out of three, this is quite
> > confusing (as to me to an electrical engineer) and I hardly believe
> > it's the same in the datasheet (however nowadays everything is
> > possible with (ab)use of Unicode).
>
> I think this is "only" a misrepresentation on your end.

I think it depends on all possible compositions of the fonts, glyphs
and unicode libraries, now since I looked at the lore.kernel.org (via
the same browser!) I see a different appearance of this, i.e. it now
has one dash on top of both R and D and one (still misaligned) on top
of R on top of the first dash, the thickness of them is also different
there.

> Sometimes it
> happens for me, too. A forced redraw helps then. I think that's a bug in
> the unicode render engine. In gitk it looks completely wrong.
> Syntactically it's correct however, the sequence is:
> \xcc\x85R\xcc\x85D\xcc\x85Y, where "\xcc\x85" is the UTF-8
> representation of the "combining overline" code point (0x305).

With all this said, please, change it to a less confusing (dependent
to external libraries/tools) way.

> That makes me remember the times when having a non-ASCII char in your
> name was a problem:

Your name in UTF-8 looks nice to me, the below is different character
set mis-conversions, but it's not the same as we are talking here
about.

> $ git log v6.13-rc1 | grep -P -o 'Kleine-K.*?nig' | sort | uniq -c
>       8 Kleine-König
>       1 Kleine-K=C3=B6nig
>       1 Kleine-K=F6nig
>       1 Kleine-K?nig
>      10 Kleine-Knig
>     156 Kleine-Koenig
>       8 Kleine-Konig
>   12862 Kleine-König
>       1 Kleine-K <u.kleine-koenig
>
> If we don't start using these, it will never be repaired ...

Sometimes it's better not to start at all... :-)

-- 
With Best Regards,
Andy Shevchenko





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux