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: <cffe100e-1883-858a-51a1-236da282b8c0@ti.com>
Date:   Fri, 26 May 2017 11:31:40 -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" <kernel-janitors@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/1] w1: Add subsystem kernel public interface

On 05/26/2017 11:13 AM, Evgeniy Polyakov wrote:
> 
> 
> 25.05.2017, 16:50, "Andrew F. Davis" <afd@...com>:
> 
>>>  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).
> 
> One still has to jump between kconfig menus to enable w1 and power devices,
> or to use 'select', nothing really changes.
> 

Well, one less step in that we get to drop the platform shim driver, but
I see what you mean.

>> 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.
> 
> Ok, lets merge it.

Great, thanks!

> 
> My personal note: please drop TI copyright from headers, at least from those which already exist
> and you move them around, it is your work and not TI. It is up to you to put into driver itself.
> 

9-5 TI owns everything I touch :) so I just figured I should add it, but
I have no personal problem dropping the copyright notice (actually I
already did this as you requested this in v1).