linux-kernel - Re: [Gta04-owner] [PATCH 0/3] tty slave device support

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

Date:	Fri, 20 Mar 2015 19:43:07 +1100
From:	NeilBrown <neilb@...e.de>
To:	"Dr. H. Nikolaus Schaller" <hns@...delico.com>
Cc:	Mark Rutland <mark.rutland@....com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Peter Hurley <peter@...leysoftware.com>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sebastian Reichel <sre@...nel.org>,
	Pavel Machek <pavel@....cz>,
	Grant Likely <grant.likely@...aro.org>,
	Jiri Slaby <jslaby@...e.cz>, devicetree@...r.kernel.org,
	lkml <linux-kernel@...r.kernel.org>,
	Belisko Marek <marek.belisko@...il.com>,
	List for communicating with real GTA04 owners 
	<gta04-owner@...delico.com>
Subject: Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

On Fri, 20 Mar 2015 08:54:35 +0100 "Dr. H. Nikolaus Schaller"
<hns@...delico.com> wrote:

> Hi Neil,
> 
> Am 18.03.2015 um 06:58 schrieb NeilBrown <neil@...wn.name>:
> 
> > Hi again,
> > here is version 3 of support for tty-slaves.
> > 
> > This version introduces a new bus-type for tty-slaves,
> 
> Hm. I am still not convinced that a tty is a „bus“ and 
> that this is a solution for a wide-spread problem.

Don't read too much into the word "bus".  It is really just a mechanism for
grouping drivers together - with maybe a hint of a suggestions that it helps
communicate with the devices which the drivers drive.

And I'm not particularly interested in solving wide-spread problems, just in
solving my problem in a suitably idiomatic way.


> 
> > and causes
> > a tty-slave device to appear in /sys/devices between the uart and the
> > tty.
> > It effectively intercepts and calls from the tty to the uart (i.e. any
> > tty_operations) and applies extra functionality at that point.
> 
> > 
> > Currently the only driver intercepts open and close.
> > It powers on the device on open, and powers off at last-close.
> 
> That is what the missing piece in Linux is to make the w2sg0004
> chip work.
> 
> > 
> > Power can be controlled by a regulator or by toggling a GPIO.
> 
> I think such a GPIO logic has nothing to do with serial and
> should be left over to the regulator logic, i.e. we need a special
> regulator-w2sg0004 driver.
> 
> So I suggest to remove the GPIO logic from your 
> 
> drivers/tty/slave/serial-power-manager.c
> 
> And then you can even get rid of adding a chip specific „compatible“
> entry for the subnodes.

But (nearly) every node has a "compatible" entry.
Each node describes a device, and the "compatible" string tells us what sort
of device.
Surely you agree that there is a particular device that needs to be
controlled?  In that case there needs to be a node representing it and a
"compatible" string describing it.  That is how "devicetree" works.


> 
> > 
> > I think I've incorporated most of the feed back I received from
> > previous versions, but if I missed something - I apologize.  If
> > this approach is structurally acceptable then I can fix up all the
> > smaller issues.
> 
> As said I would prefer that the w2sg0004 driver is just a separate
> „regulator“ driver as we had proposed before.

You can prefer that if you wish.  But given that the w2sg0004 is not in fact
a regulator, but is in fact a GPS device, I doubt you will find a lot of
support for your approach (as indeed I didn't when I tried it...)

Thanks,
NeilBrown


Content of type "application/pgp-signature" skipped