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]
Date:   Mon, 16 May 2022 18:03:12 -0700
From:   Zev Weiss <zev@...ilderbeest.net>
To:     Mark Brown <broonie@...nel.org>
Cc:     Chanwoo Choi <cwchoi00@...il.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        MyungJoo Ham <myungjoo.ham@...sung.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        openbmc@...ts.ozlabs.org,
        Sebastian Reichel <sebastian.reichel@...labora.com>
Subject: Re: [PATCH v2 2/2] extcon: Add extcon-regulator driver

[Adding Sebastian for drivers/power discussion]

On Mon, May 09, 2022 at 08:24:16AM PDT, Mark Brown wrote:
> On Mon, May 09, 2022 at 09:24:39PM +0900, Chanwoo Choi wrote:
> > Hi Zev,
> > 
> > I checked this patch. But, it doesn't look like the extcon provider
> > driver. Because basically, extcon provider driver need the circuit
> > in order to detect the kind of external connector. But, there are
> > no any code for detection. Just add the specific sysfs attribute
> > for only this driver. It is not standard interface.
> 
> OTOH it's something where if I look at the physical system with the
> hardware there's a clearly visible external connector that I can point
> to - it just happens to not support hotplug.  It's not clear what other
> system it would sit in, and it seems like an application that displays
> external connections on a system in a UI would be able to do something
> sensible with it.

Chanwoo, any further thoughts on Mark's reasoning above?

I certainly understand the reluctance to add an extcon driver that 
doesn't really do anything with the extcon API, and I have no idea when 
we might end up enhancing it to do something more meaningful with that 
API (I don't know of any hardware at the moment that would need it).

That said, as Mark points out, the hardware *is* ultimately an "external 
connector" (if a very simplistic one).

Do you have any other ideas for where this functionality could go?  Greg 
wasn't enthusiastic about a previous revision that had it in 
drivers/misc -- though now a fair amount of what was in that version is 
now going to be in the regulator core, so maybe that could be 
reconsidered?

Or maybe something under drivers/power, though it's not really a supply 
or a reset device...drivers/power/output.c or something?

Personally I don't have any terribly strong opinions on this, I'd just 
like to reach a mutually-agreeable consensus on a place for it to live.


Thanks,
Zev

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ