public inbox for kernel-janitors@vger.kernel.org
 help / color / mirror / Atom feed
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, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/1] w1: Add subsystem kernel public interface
Date: Thu, 25 May 2017 13:47:19 +0000	[thread overview]
Message-ID: <adfa6c6b-84b8-d652-c76b-04138e4248fb@ti.com> (raw)
In-Reply-To: <1604131495718924@web38g.yandex.ru>

On 05/25/2017 08:28 AM, Evgeniy Polyakov wrote:
> 
> 
> 25.05.2017, 16:22, "Andrew F. Davis" <afd@ti.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.

  parent reply	other threads:[~2017-05-25 13:47 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 ` [PATCH v2 1/1] w1: Add subsystem kernel public interface 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 [this message]
     [not found]               ` <3947221495815182@web23o.yandex.ru>
2017-05-26 16:31                 ` Andrew F. Davis
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=adfa6c6b-84b8-d652-c76b-04138e4248fb@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