linux-kernel - Re: [PATCH v2 1/1] w1: Add subsystem kernel public interface

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>] [day] [month] [year] [list]

Message-ID: <adfa6c6b-84b8-d652-c76b-04138e4248fb@ti.com>
Date:   Thu, 25 May 2017 08:47:19 -0500
From:   "Andrew F. Davis" <afd@...com>
To:     Evgeniy Polyakov <zbr@...emap.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     Sebastian Reichel <sre@...nel.org>,
        <kernel-janitors@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/1] w1: Add subsystem kernel public interface

On 05/25/2017 08:28 AM, Evgeniy Polyakov wrote:
> 
> 
> 25.05.2017, 16:22, "Andrew F. Davis" <afd@...com>:
> 
>>>  Why does BQ27xxx need to move out of w1 tree?
>>
>> Currently we have to enable a pseudo-platform device driver in the
>> power/supply BQ27xxx driver, then the w1 driver has to instantiate this
>> platform device and then they connect and communicate by sharing
>> callbacks. This is rather hacky.
> 
> Why do you have to create a pseudo-platform device driver to connect w1 and power/supply?
> 
> I'm not against creating w1 drivers in different places than drivers/w1, but so far
> it was only power drivers which have problem with it (and they easily work it out),
> and this rises a flag.
> 

We could keep it in w1 if we really wanted, but then things like Kconfig
will get difficult to manage (we will jump between menus and have odd
dependencies).

The other w1/slaves seem to mostly be simple EEPROMs and Gauges that
would otherwise end up in misc/ so it is fine if they live in w1, but
BQ27xxx does have a proper home in power/supplies and its i2c interface
is already there, so moving the w1 interface there also makes sense to me.

> I would rather move w1 header into include/linux, will it be enough?
> 

That's what this patch does, we just also re-organize things a bit so
only things that need to be public end up in include/linux. It seems to
be all that is needed for my use-case at least.