All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Kemnade <andreas@kemnade.info>
To: Johan Hovold <johan@kernel.org>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
	devicetree@vger.kernel.org,
	"Discussions about the Letux Kernel"
	<letux-kernel@openphoenux.org>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Tony Lindgren" <tony@atomide.com>,
	"H. Nikolaus Schaller" <hns@goldelico.com>,
	kernel@pyra-handheld.com, "Russell King" <linux@armlinux.org.uk>,
	linux-kernel@vger.kernel.org,
	"Thierry Reding" <treding@nvidia.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Benoît Cousson" <bcousson@baylibre.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	linux-omap@vger.kernel.org, "Andreas Färber" <afaerber@suse.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver
Date: Fri, 12 Jan 2018 19:40:35 +0100	[thread overview]
Message-ID: <20180112194022.7da1e726@kemnade.info> (raw)
In-Reply-To: <20180112144647.GA5992@localhost>

[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]

On Fri, 12 Jan 2018 15:46:47 +0100
Johan Hovold <johan@kernel.org> wrote:

> On Tue, Jan 09, 2018 at 06:43:47PM +0100, Andreas Kemnade wrote:
> > On Fri, 22 Dec 2017 13:44:27 +0100
> > Johan Hovold <johan@kernel.org> wrote:
> > 
> > [...]  
> > > I'd suggest reiterating the problem you're trying to solve and
> > > enumerating the previously discussed potential solutions in order to
> > > find a proper abstraction level for this (before getting lost in
> > > implementation details).
> > >   
> > The main point here is in short words: Having a device powered on or off
> > when the uart it is attached to, is used or not used anymore,
> > so the already available userspace applications do not need to be changed.  
> 
> So we'd end up with something in-between a kernel driver and a
> user-space solution. What about devices that need to be (partially)
> powered also when the port isn't open? A pure user-space solution would
> be able to handle all variants.
> 
Well partly powered devices are at many places, And they hide that problem
from userspace, just get the open()/get() and close()/put() from there and power the
device accordingly. 

So the question still remains why should the kernel hide some things and some
it should not.
If it all is in userspace, then there is still something needed in the devicetree
(if I understand correctly, every information about hardware which cannot be
auto-probed belongs into device tree) so that the userspace knows what kind of
device is at that port. So there can be a daemon powering on and off devices.
But that would break existing applications which just expect that they just need
to open/close the device. 

Or you need to have some inotify handler in userspace and attach it there to
react on close() and open() of that device.
But this thing needs to have two kind of information:

1. the type of chip available to do the right powerup sequence. 

2. how the chip is wired up to the cpu. 

So to avoid having hardware information spread all over the table at least
these information would need to be in devicetree. But that also all feels
like a hack and hard to maintain.

Regards,
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Andreas Kemnade <andreas-cLv4Z9ELZ06ZuzBka8ofvg@public.gmane.org>
To: Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: "Mark Rutland" <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Discussions about the Letux Kernel"
	<letux-kernel-S0jZdbWzriLCfDggNXIi3w@public.gmane.org>,
	"Jonathan Cameron"
	<jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"Arnd Bergmann" <arnd-r2nGTMty4D4@public.gmane.org>,
	"Tony Lindgren" <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>,
	"H. Nikolaus Schaller"
	<hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>,
	kernel-Jl6IXVxNIMRxAtABVqVhTwC/G2K4zDHf@public.gmane.org,
	"Russell King" <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Thierry Reding"
	<treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	"Rob Herring" <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"Kevin Hilman" <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	"Benoît Cousson"
	<bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	"Greg Kroah-Hartman"
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Andreas Färber" <afaerber-l3A5Bk7waGM@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver
Date: Fri, 12 Jan 2018 19:40:35 +0100	[thread overview]
Message-ID: <20180112194022.7da1e726@kemnade.info> (raw)
In-Reply-To: <20180112144647.GA5992@localhost>

[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]

On Fri, 12 Jan 2018 15:46:47 +0100
Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:

> On Tue, Jan 09, 2018 at 06:43:47PM +0100, Andreas Kemnade wrote:
> > On Fri, 22 Dec 2017 13:44:27 +0100
> > Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > 
> > [...]  
> > > I'd suggest reiterating the problem you're trying to solve and
> > > enumerating the previously discussed potential solutions in order to
> > > find a proper abstraction level for this (before getting lost in
> > > implementation details).
> > >   
> > The main point here is in short words: Having a device powered on or off
> > when the uart it is attached to, is used or not used anymore,
> > so the already available userspace applications do not need to be changed.  
> 
> So we'd end up with something in-between a kernel driver and a
> user-space solution. What about devices that need to be (partially)
> powered also when the port isn't open? A pure user-space solution would
> be able to handle all variants.
> 
Well partly powered devices are at many places, And they hide that problem
from userspace, just get the open()/get() and close()/put() from there and power the
device accordingly. 

So the question still remains why should the kernel hide some things and some
it should not.
If it all is in userspace, then there is still something needed in the devicetree
(if I understand correctly, every information about hardware which cannot be
auto-probed belongs into device tree) so that the userspace knows what kind of
device is at that port. So there can be a daemon powering on and off devices.
But that would break existing applications which just expect that they just need
to open/close the device. 

Or you need to have some inotify handler in userspace and attach it there to
react on close() and open() of that device.
But this thing needs to have two kind of information:

1. the type of chip available to do the right powerup sequence. 

2. how the chip is wired up to the cpu. 

So to avoid having hardware information spread all over the table at least
these information would need to be in devicetree. But that also all feels
like a hack and hard to maintain.

Regards,
Andreas

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: andreas@kemnade.info (Andreas Kemnade)
To: linux-arm-kernel@lists.infradead.org
Subject: [Letux-kernel] [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver
Date: Fri, 12 Jan 2018 19:40:35 +0100	[thread overview]
Message-ID: <20180112194022.7da1e726@kemnade.info> (raw)
In-Reply-To: <20180112144647.GA5992@localhost>

On Fri, 12 Jan 2018 15:46:47 +0100
Johan Hovold <johan@kernel.org> wrote:

> On Tue, Jan 09, 2018 at 06:43:47PM +0100, Andreas Kemnade wrote:
> > On Fri, 22 Dec 2017 13:44:27 +0100
> > Johan Hovold <johan@kernel.org> wrote:
> > 
> > [...]  
> > > I'd suggest reiterating the problem you're trying to solve and
> > > enumerating the previously discussed potential solutions in order to
> > > find a proper abstraction level for this (before getting lost in
> > > implementation details).
> > >   
> > The main point here is in short words: Having a device powered on or off
> > when the uart it is attached to, is used or not used anymore,
> > so the already available userspace applications do not need to be changed.  
> 
> So we'd end up with something in-between a kernel driver and a
> user-space solution. What about devices that need to be (partially)
> powered also when the port isn't open? A pure user-space solution would
> be able to handle all variants.
> 
Well partly powered devices are at many places, And they hide that problem
from userspace, just get the open()/get() and close()/put() from there and power the
device accordingly. 

So the question still remains why should the kernel hide some things and some
it should not.
If it all is in userspace, then there is still something needed in the devicetree
(if I understand correctly, every information about hardware which cannot be
auto-probed belongs into device tree) so that the userspace knows what kind of
device is at that port. So there can be a daemon powering on and off devices.
But that would break existing applications which just expect that they just need
to open/close the device. 

Or you need to have some inotify handler in userspace and attach it there to
react on close() and open() of that device.
But this thing needs to have two kind of information:

1. the type of chip available to do the right powerup sequence. 

2. how the chip is wired up to the cpu. 

So to avoid having hardware information spread all over the table at least
these information would need to be in devicetree. But that also all feels
like a hack and hard to maintain.

Regards,
Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180112/516f978d/attachment.sig>

  reply	other threads:[~2018-01-12 18:41 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-01  7:49 [PATCH v5 0/5] misc serdev: new serdev based driver for Wi2Wi w2sg00x4 GPS module H. Nikolaus Schaller
2017-12-01  7:49 ` H. Nikolaus Schaller
2017-12-01  7:49 ` [PATCH v5 1/5] dt-bindings: define vendor prefix for Wi2Wi, Inc H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-01 14:44   ` Andreas Färber
2017-12-01 14:44     ` Andreas Färber
2017-12-01  7:49 ` [PATCH v5 2/5] dt-bindings: gps: add w2sg00x4 bindings documentation (GPS module with UART)) H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-01  7:49 ` [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-22 12:44   ` Johan Hovold
2017-12-22 12:44     ` Johan Hovold
2017-12-22 12:44     ` Johan Hovold
2017-12-22 14:40     ` H. Nikolaus Schaller
2017-12-22 14:40       ` H. Nikolaus Schaller
2017-12-22 14:40       ` H. Nikolaus Schaller
2018-01-09 11:55       ` [Letux-kernel] " H. Nikolaus Schaller
2018-01-09 11:55         ` H. Nikolaus Schaller
2018-01-09 11:55         ` H. Nikolaus Schaller
2018-01-12 15:39         ` Johan Hovold
2018-01-12 15:39           ` Johan Hovold
2018-01-12 15:39           ` Johan Hovold
2018-01-12 17:59           ` H. Nikolaus Schaller
2018-01-12 17:59             ` H. Nikolaus Schaller
2018-01-12 17:59             ` H. Nikolaus Schaller
2018-01-18  6:13             ` Johan Hovold
2018-01-18  6:13               ` Johan Hovold
2018-01-18  6:13               ` Johan Hovold
2018-01-18 13:43               ` H. Nikolaus Schaller
2018-01-18 13:43                 ` H. Nikolaus Schaller
2018-01-18 13:43                 ` H. Nikolaus Schaller
2018-03-07 15:53                 ` H. Nikolaus Schaller
2018-03-07 15:53                   ` H. Nikolaus Schaller
2018-03-07 15:53                   ` H. Nikolaus Schaller
2018-03-19 14:05                   ` Johan Hovold
2018-03-19 14:05                     ` Johan Hovold
2018-03-19 14:05                     ` Johan Hovold
2018-02-12 15:26           ` [Letux-kernel] " Pavel Machek
2018-02-12 15:26             ` Pavel Machek
2018-02-12 15:26             ` Pavel Machek
2018-02-27  7:04             ` Johan Hovold
2018-02-27  7:04               ` Johan Hovold
2018-02-27  7:04               ` Johan Hovold
2018-02-27  7:32               ` H. Nikolaus Schaller
2018-02-27  7:32                 ` H. Nikolaus Schaller
2018-02-27  7:32                 ` H. Nikolaus Schaller
2018-03-19 13:54                 ` Johan Hovold
2018-03-19 13:54                   ` Johan Hovold
2018-03-19 13:54                   ` Johan Hovold
2018-03-20 14:49                   ` H. Nikolaus Schaller
2018-03-20 14:49                     ` H. Nikolaus Schaller
2018-03-20 14:49                     ` H. Nikolaus Schaller
2018-03-26 13:59                     ` Pavel Machek
2018-03-26 13:59                       ` Pavel Machek
2018-02-27 18:38               ` Pavel Machek
2018-02-27 18:38                 ` Pavel Machek
2018-02-27 18:38                 ` Pavel Machek
2018-02-12 15:25         ` Pavel Machek
2018-02-12 15:25           ` Pavel Machek
2018-01-09 17:43     ` Andreas Kemnade
2018-01-09 17:43       ` Andreas Kemnade
2018-01-09 17:43       ` Andreas Kemnade
2018-01-12 14:46       ` Johan Hovold
2018-01-12 14:46         ` Johan Hovold
2018-01-12 18:40         ` Andreas Kemnade [this message]
2018-01-12 18:40           ` Andreas Kemnade
2018-01-12 18:40           ` Andreas Kemnade
2018-01-18  6:47           ` Johan Hovold
2018-01-18  6:47             ` Johan Hovold
2018-01-18  6:47             ` Johan Hovold
2018-03-08  6:16             ` Andreas Kemnade
2018-03-08  6:16               ` Andreas Kemnade
2018-03-19 14:02               ` Johan Hovold
2018-03-19 14:02                 ` Johan Hovold
2017-12-01  7:49 ` [PATCH v5 4/5] DTS: gta04: add uart2 child node for w2sg00x4 H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-21 14:53   ` Tony Lindgren
2017-12-21 14:53     ` Tony Lindgren
2017-12-21 14:53     ` Tony Lindgren
2017-12-01  7:49 ` [PATCH v5 5/5] misc serdev: w2sg0004: add debugging code and Kconfig H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-01  7:49   ` H. Nikolaus Schaller
2017-12-22 12:51   ` Johan Hovold
2017-12-22 12:51     ` Johan Hovold
2017-12-22 12:51     ` Johan Hovold
2017-12-22 14:41     ` H. Nikolaus Schaller
2017-12-22 14:41       ` H. Nikolaus Schaller
2017-12-22 14:58       ` Greg Kroah-Hartman
2017-12-22 14:58         ` Greg Kroah-Hartman
2017-12-22 14:58         ` Greg Kroah-Hartman
2017-12-18  8:52 ` [PATCH v5 0/5] misc serdev: new serdev based driver for Wi2Wi w2sg00x4 GPS module H. Nikolaus Schaller
2017-12-18  8:52   ` H. Nikolaus Schaller
2017-12-18  8:52   ` H. Nikolaus Schaller
2017-12-18 14:48   ` Greg Kroah-Hartman
2017-12-18 14:48     ` Greg Kroah-Hartman
2017-12-18 14:52     ` H. Nikolaus Schaller
2017-12-18 14:52       ` H. Nikolaus Schaller
2017-12-18 14:52       ` H. Nikolaus Schaller

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=20180112194022.7da1e726@kemnade.info \
    --to=andreas@kemnade.info \
    --cc=afaerber@suse.de \
    --cc=arnd@arndb.de \
    --cc=bcousson@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hns@goldelico.com \
    --cc=jic23@kernel.org \
    --cc=johan@kernel.org \
    --cc=kernel@pyra-handheld.com \
    --cc=khilman@baylibre.com \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=tony@atomide.com \
    --cc=treding@nvidia.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.