linux-kernel - [PATCH v10 0/3] leds: trigger: implement a tty trigger

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 PHC
Open Source and information security mailing list archives

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

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

Date:   Fri, 18 Dec 2020 11:42:43 +0100
From:   Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>, Dan Murphy <dmurphy@...com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>
Cc:     linux-serial@...r.kernel.org, linux-leds@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel@...gutronix.de,
        Johan Hovold <johan@...nel.org>,
        Uwe Kleine-König <uwe@...ine-koenig.org>
Subject: [PATCH v10 0/3] leds: trigger: implement a tty trigger

From: Uwe Kleine-König <uwe@...ine-koenig.org>

Hello,

here comes v10 of this series. Changes compared to v9 sent with
Message-Id: 20201018204022.910815-1-u.kleine-koenig@...gutronix.de in
October:

 - Bump date and kernel version in ABI doc
 - Fix double unlock in error path; found by Pavel
 - Don't stop the workqueue in ttyname_store() to
   fix error behaviour on memory allocation failure.
   Now it continues with the previous configuration instead of
   stopping. Also found by Pavel.

Unaddressed review comments by Pavel are:

 - Unused assignment to len in ttyname_show
   This is wrong
 - "Poll every 100 msec... Hmm.... Okay, I guess?"
   Yes, I think there is no way around this given the trigger uses
   polling. There is no easy way to get notified instead.
 - "Are you sure about LED_ON [in the worker]? It should use current
   brightness selected by brightness file..."
   I found no consistent behaviour in other triggers. ledtrig-gpio
   implements a dedicated "desired_brightness" sysfs file, several use
   led_cdev->blink_brightness (via led_trigger_blink_oneshot),
   ledtrig-cpu uses led_trigger_event with LED_FULL.
 - "How is [the data initialized in ledtrig_tty_activate()] protected
   from concurrent access from sysfs?"
   I think there is no need to protect this. But I'm not sure I
   understood the question correctly, so please recheck and if needed
   point out the problem you see in more detail.

Uwe Kleine-König (3):
  tty: rename tty_kopen() and add new function tty_kopen_shared()
  tty: new helper function tty_get_icount()
  leds: trigger: implement a tty trigger

 .../ABI/testing/sysfs-class-led-trigger-tty   |   6 +
 drivers/accessibility/speakup/spk_ttyio.c     |   2 +-
 drivers/leds/trigger/Kconfig                  |   9 +
 drivers/leds/trigger/Makefile                 |   1 +
 drivers/leds/trigger/ledtrig-tty.c            | 188 ++++++++++++++++++
 drivers/tty/tty_io.c                          |  85 ++++++--
 include/linux/tty.h                           |   7 +-
 7 files changed, 273 insertions(+), 25 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-tty
 create mode 100644 drivers/leds/trigger/ledtrig-tty.c

-- 
2.29.2