linux-kernel - Re: [PATCH v2 00/19] Dynamically load/remove serdev devices via sysfs*

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: <20180614104820.GC32411@localhost>
Date:   Thu, 14 Jun 2018 12:48:20 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
        Rob Herring <robh@...nel.org>, Johan Hovold <johan@...nel.org>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH v2 00/19] Dynamically load/remove serdev devices via
 sysfs*

Hi Ricardo, 

On Mon, Jun 11, 2018 at 01:52:16PM +0200, Ricardo Ribalda Delgado wrote:
> There are some situations where it is interesting to load/remove serdev
> devices dynamically, like during board bring-up or when we are
> developing a new driver or for devices that are neither described via
> ACPI or device tree.

First of all, this would be more appropriately labeled an RFC as this is
far from being in a mergeable state. Besides some implementation issues,
we need to determine if this approach is at all viable.

Second, I wonder how you tested this given that this series breaks RX
(and write-wakeup signalling) for serial ports (patch 19/24)?

Third, and as Marcel already suggested, you need to limit your scope
here. Aim at ten patches or so, and use a representative serdev driver
as an example of the kind of driver updates that would be needed. It
also looks like some patches should be squashed (e.g. the ones
introducing new fields and the first one actually using them).

> This implementation allows the creation of serdev devices via sysfs,
> in a similar way as the i2c bus allows sysfs instantiation [1].

Note that this is a legacy interface and not necessarily something that
new interfaces should be modelled after.

Johan