linux-kernel - Re: [PATCH 1/3] auxdisplay: charlcd: fix hex literal ranges for graphics command

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20180225235432.31209-1-rabel@robertabel.eu>
Date:   Mon, 26 Feb 2018 00:54:28 +0100
From:   Robert Abel <rabel@...ertabel.eu>
To:     linux-kernel <linux-kernel@...r.kernel.org>
Cc:     Robert Abel <rabel@...ertabel.eu>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        Willy Tarreau <w@....eu>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH 1/3] auxdisplay: charlcd: fix hex literal ranges for
 graphics command

The following patch set fixes the x/y coordinate addressing issue I mentioned earlier
as well as not marking the two-line command sequence as processed resulting in a confusing
state.

I implemented the logic around using kstrtoul by terminating the substrings that contain
numbers for each command separately and then restoring the command character following the
number that was overwritten.

Additionally, the code now doesn't write live to the x and y address fields and will
bail out if an unknown command character or an invalid number was encountered.

I did try to keep it backwards compatible, so sequences of the form ^[[Lx0y1x2y4; will
still work (and result in x2y4).

Additionally, I noticed that the ^[[H home function was just resetting the x/y coordinates
but not the display shift, which results in a situation where the display cannot be
programmatically unshifted (except for init ^[[LI). So I implemented the HOME command 0x02
for charlcd_home. The old behavior can be simulated using ^[[Lx0y0; (just reset x/y, don't
unshift).

I tested on my Raspberry Pi Zero W with a clone 1602 display.

Robert Abel (4):
  auxdisplay: charlcd: fix two-line command ^[[LN not marked as
    processed
  auxdisplay: charlcd: name x/y address struct
  auxdisplay: charlcd: fix x/y address commands
  auxdisplay: charlcd: make home command unshift display

 drivers/auxdisplay/charlcd.c | 76 ++++++++++++++++++++++++++++++++++----------
 1 file changed, 60 insertions(+), 16 deletions(-)

-- 
2.11.0