From: "Andrew F. Davis" <afd@ti.com>
To: Evgeniy Polyakov <zbr@ioremap.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sebastian Reichel <sre@kernel.org>,
"kernel-janitors@vger.kernel.org"
<kernel-janitors@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/1] w1: Add subsystem kernel public interface
Date: Fri, 26 May 2017 11:31:40 -0500 [thread overview]
Message-ID: <cffe100e-1883-858a-51a1-236da282b8c0@ti.com> (raw)
In-Reply-To: <3947221495815182@web23o.yandex.ru>
On 05/26/2017 11:13 AM, Evgeniy Polyakov wrote:
>
>
> 25.05.2017, 16:50, "Andrew F. Davis" <afd@ti.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).
next prev parent reply other threads:[~2017-05-26 16:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170516200814.12360-1-afd@ti.com>
2017-05-16 20:08 ` Andrew F. Davis
2017-05-25 13:00 ` Greg Kroah-Hartman
2017-05-25 13:07 ` Andrew F. Davis
[not found] ` <1499591495717767@web38g.yandex.ru>
2017-05-25 13:21 ` Andrew F. Davis
[not found] ` <1604131495718924@web38g.yandex.ru>
2017-05-25 13:47 ` Andrew F. Davis
[not found] ` <3947221495815182@web23o.yandex.ru>
2017-05-26 16:31 ` Andrew F. Davis [this message]
2017-06-03 10:22 ` Greg Kroah-Hartman
2017-06-05 13:57 ` Andrew F. Davis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cffe100e-1883-858a-51a1-236da282b8c0@ti.com \
--to=afd@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sre@kernel.org \
--cc=zbr@ioremap.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®