Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
CC-ing author of below reply On Sat, Jun 6, 2015 at 8:53 PM, Belisko Marek wrote: > On Sat, Jun 6, 2015 at 3:09 PM, Pavel Machek wrote: >> Hi! >> >>> None was ?wonderful?. They were valid concerns about my proposal >>> and I have replied to them how I see it. >>> >>> Generally, if you are not interested in people dedicated and committed to >>> fight for the better solution with (technical) arguments and concrete >>> proposals >>> how it should be in their opinion, then please just tell and I will shut up. >>> But only then. >> >> Whatever, if it makes you shut up: >> >> I'm not interested in . >> >>> Or if some DT maintainer makes a decision and says: I have listened and >>> understood all arguments pro and con and I decide this or that way >>> (preferrably >>> with giving reasons of decision as a guidance for similar problems in the >>> future). >> >> The DT maintainers are saying just that for 10 mails now, as anybody who >> understands >> english will agree. >> >> You are behaving like a troll. Go away. > Please stop this non constructive emails. You don't need to reply with > reply like this. Nikolaus > post his version and wait for conclusion and feedback from maintainers. > I suggest you to read : Documentation/CodeOfConflict. Thanks. >> >> >>Pavel >> >> -- >> (english) http://www.livejournal.com/~pavelmachek >> (cesky, pictures) >> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html >> ___ >> Gta04-owner mailing list >> gta04-ow...@goldelico.com >> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner > > BR, > > marek > > -- > as simple and primitive as possible > - > Marek Belisko - OPEN-NANDRA > Freelance Developer > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic > Tel: +421 915 052 184 > skype: marekwhite > twitter: #opennandra > web: http://open-nandra.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
On Sat, Jun 6, 2015 at 3:09 PM, Pavel Machek wrote: > Hi! > >> None was ?wonderful?. They were valid concerns about my proposal >> and I have replied to them how I see it. >> >> Generally, if you are not interested in people dedicated and committed to >> fight for the better solution with (technical) arguments and concrete >> proposals >> how it should be in their opinion, then please just tell and I will shut up. >> But only then. > > Whatever, if it makes you shut up: > > I'm not interested in . > >> Or if some DT maintainer makes a decision and says: I have listened and >> understood all arguments pro and con and I decide this or that way >> (preferrably >> with giving reasons of decision as a guidance for similar problems in the >> future). > > The DT maintainers are saying just that for 10 mails now, as anybody who > understands > english will agree. > > You are behaving like a troll. Go away. Please stop this non constructive emails. You don't need to reply with reply like this. Nikolaus post his version and wait for conclusion and feedback from maintainers. I suggest you to read : Documentation/CodeOfConflict. Thanks. > > > Pavel > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > ___ > Gta04-owner mailing list > gta04-ow...@goldelico.com > http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi! > None was ?wonderful?. They were valid concerns about my proposal > and I have replied to them how I see it. > > Generally, if you are not interested in people dedicated and committed to > fight for the better solution with (technical) arguments and concrete > proposals > how it should be in their opinion, then please just tell and I will shut up. > But only then. Whatever, if it makes you shut up: I'm not interested in . > Or if some DT maintainer makes a decision and says: I have listened and > understood all arguments pro and con and I decide this or that way > (preferrably > with giving reasons of decision as a guidance for similar problems in the > future). The DT maintainers are saying just that for 10 mails now, as anybody who understands english will agree. You are behaving like a troll. Go away. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Pavel, Am 06.05.2015 um 11:27 schrieb Pavel Machek : > On Wed 2015-05-06 07:19:31, Dr. H. Nikolaus Schaller wrote: >> Hi Peter, >> >> Am 05.05.2015 um 21:54 schrieb Peter Hurley : >> >>> Hi Neil, >>> >>> On 03/18/2015 01:58 AM, NeilBrown wrote: here is version 3 of support for tty-slaves. >>> >>> Is there a v4 of this that I missed? >> >> We did have a lengthy discussion about [PATCH 3/3] how to best (1) >> represent the slave device in the device tree but as far as I am concerned, >> I do not see that we have a consensus (2) and the device tree maintainers >> have no comments or clear guidelines so far. > > Yes. Everyone and their dog disagrees What a wonderful argument… I still ask myself who the dog is. > with Nikolaus, who is playing > devil's advocate I hope you don't think that Linux users are devils… No, I am not playing devil’s advocate (which would imply that I am doing this for fun to tease the dog), but I feel I have to be the advocate of future board designers who want to easily import an existing board DT and overwrite device tree nodes to describe design changes, i.e. what slave device is connected to which uart. At least in this regard, the alternatives are really differently easy to handle. And, the alternatives have some influence how a tty driver and a slave device driver is designed. So that is for me the root question, before discussing (some) implementation details. Because it is not resolved in a way that convinces me (and future board DT designers), I bring it up again and again. Even if you and some dog apparently disagree. > here, so we clearly have to get confirmation from > device tree maintainers. And when they disagree with him, we'll need > to get concensus from Linus, too... > Pavel BR, Nikolaus-- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Nikolaus, On 05/06/2015 01:19 AM, Dr. H. Nikolaus Schaller wrote: > Am 05.05.2015 um 21:54 schrieb Peter Hurley : > >> Hi Neil, >> >> On 03/18/2015 01:58 AM, NeilBrown wrote: >>> here is version 3 of support for tty-slaves. >> >> Is there a v4 of this that I missed? > > We did have a lengthy discussion about [PATCH 3/3] how to best (1) > represent the slave device in the device tree but as far as I am concerned, > I do not see that we have a consensus (2) and the device tree maintainers > have no comments or clear guidelines so far. I understand there are some design considerations still apparently unresolved wrt devicetree representation. However, there were significant lifetime issues in v3 and I'd like some time to review v4 to understand how those were resolved, and study the implications. Maintainers are busy people and often don't provide design steering until the other pieces are ack'd. I'd like to see _a_ solution eventually, so let's move this process along. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi,
On Fri, Mar 20, 2015 at 02:57:12PM +0100, Dr. H. Nikolaus Schaller wrote:
> > On Fri, Mar 20, 2015 at 09:54:21AM +0100, Dr. H. Nikolaus Schaller wrote:
> >> [...]
> >> And we do not write a driver for the w2sg0004 but the regulator inside that
> >> chip.
> >
> > DT describes the hardware structure and not the Linux driver
> > structure.
>
> I am not advocating for describing the Linux driver structure in DT.
> Rather I suggest that the DT should describe hardware and there
> is a regulator inside that chip…
some drivers also have embedded clocks, which are not described,
since they are only useful for the device itself. Exposing them
is not useful.
> Linux drivers can follow that or mix everything into a single
> driver if that is better.
The DT binding is completly independent of drivers.
> >> You also won’t expect that the omap3 driver hides everything. You
> >> expect that the twl4030 provides some regulators that can be enabled
> >> by subsystems inside the omap3. And if I remember correctly there are
> >> regulators inside the omap3 which have explicit regulator nodes in the DT.
> >
> > so let's have a look at twl regulators. They can be found below
> > the twl node, so they will look similar to
> >
> > / -> omap3 -> i2c -> twl -> regulator
> >
> > So properly mapped to the w2sg0004 device this would put your
> > regulator to
> >
> > / -> omap3 -> serial -> w2sg0004 -> regulator
>
> Yes. Indeed.
>
> Currently it is
>
> omap3 -> serial -> serial-power-manager (trying to cover a multitude
> of different chips).
No. The DT is omap3 -> serial -> w2sg0004 and w2sg0004 is
handled by a generic driver. If the kernel ever gets more
specific support for UART attached gps you can simply remove
the compatible value from the generic driver and create a
specific one.
> > This will gain you nothing as far as I can tell.
>
> And because of that I think Neil’s argument isn’t for or against
> anything.
>
> >
> > Please note that subdevices under the serial node are pretty useful,
> > since then the kernel can e.g. automatically setup correct line
> > disciplines for serial attached bluetooth chips and make bluetooth
> > work out of the box.
>
> I don’t doubt that such subnodes are useful. I just object mixing
> different chips and controls into a single subnode driver.
Well the binding allows to split this into multiple drivers
in the future (if needed).
> And as soon as you want to control line disciplines from such
> a subnode, you indeed need a driver for each variant.
Obviously I do not use the generic driver, but a specific one for
this task. Very simple devices (from kernel's point of view) can
still be handled by a generic driver (as Neil does).
> So a GPS chip needing some line discipline could be
>
> > / -> omap3 -> serial -> w2sg0004 -> line-discipline
> > / -> omap3 -> serial -> w2sg0004 -> regulator
Actually no. The line discipline does not describe HW, but just
how linux handles the device. It should not be part of DT at all.
The kernel will see compatible string for w2sg0004 and load the
correct line discipline.
> And if omap3 -> serial can directly control a regulator, it can
> easily be the w2sg0004 -> regulator
sure.
> > I am aware, that the Linux kernel has no such thing for serial
> > attached GPS devices, but that's Linux specific and irrelevant
> > for the DT description.
> >
> >> The w2sg0004-regulator approach just follows this principle.
> >> Anyone willing to control the power of the w2sg0004 can use this
> >> regulator interface.
> >
> > From a HW perspective your regulator "hides" the information, that
> > there is a device attached to the serial port and instead claims,
> > that a regulator is needed to make the serial port work.
>
> Yes, without this regulator the serial port does not work. It is IMHO
> more important than stating the obvious that a serial device is
> connected to a serial port.
This is actually not correct though. The serial port does work
without the regulator. The remote side does not work without the
regulator. So the regulator should be referenced by the w2sg0004
node, so it would be
serial-port {
w2sg0004 {
w2sg_vdd: gpio-regulator { enable-gpio = <&some_gpio> };
vdd-supply = <&w2sg_vdd>;
}
}
And at this point you can simply drop the regulator stuff from DT,
since its device internal (and only adds complexity). For other
devices these kind of ressources are also not exposed in DT (e.g.
internal clocks).
> And if there is nothing to hide (the obvious serial interface
> wiring), why describe it at all?
>
> Anyways, in my proposal there will be a subnode of the uart, the
> one where it is specified that it should control the regulator of the
> w2sg.
>
> Basically, Neil’s proposal already covers this case. His bluetooth
> subnode just controls &vaux4 which turns on power for the w2cbw003
> chip.
>
> So for my view it is not really understandable why one uart subnode
> can control a regulator, and the other
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi, Am 20.03.2015 um 14:08 schrieb Sebastian Reichel : > Hi, > > On Fri, Mar 20, 2015 at 09:54:21AM +0100, Dr. H. Nikolaus Schaller wrote: >> [...] >> And we do not write a driver for the w2sg0004 but the regulator inside that >> chip. > > DT describes the hardware structure and not the Linux driver > structure. I am not advocating for describing the Linux driver structure in DT. Rather I suggest that the DT should describe hardware and there is a regulator inside that chip… Linux drivers can follow that or mix everything into a single driver if that is better. > >> You also won’t expect that the omap3 driver hides everything. You >> expect that the twl4030 provides some regulators that can be enabled >> by subsystems inside the omap3. And if I remember correctly there are >> regulators inside the omap3 which have explicit regulator nodes in the DT. > > so let's have a look at twl regulators. They can be found below > the twl node, so they will look similar to > > / -> omap3 -> i2c -> twl -> regulator > > So properly mapped to the w2sg0004 device this would put your > regulator to > > / -> omap3 -> serial -> w2sg0004 -> regulator Yes. Indeed. Currently it is omap3 -> serial -> serial-power-manager (trying to cover a multitude of different chips). > > This will gain you nothing as far as I can tell. And because of that I think Neil’s argument isn’t for or against anything. > > Please note that subdevices under the serial node are pretty useful, > since then the kernel can e.g. automatically setup correct line > disciplines for serial attached bluetooth chips and make bluetooth > work out of the box. I don’t doubt that such subnodes are useful. I just object mixing different chips and controls into a single subnode driver. And as soon as you want to control line disciplines from such a subnode, you indeed need a driver for each variant. So a GPS chip needing some line discipline could be > / -> omap3 -> serial -> w2sg0004 -> line-discipline > / -> omap3 -> serial -> w2sg0004 -> regulator And if omap3 -> serial can directly control a regulator, it can easily be the w2sg0004 -> regulator > > I am aware, that the Linux kernel has no such thing for serial > attached GPS devices, but that's Linux specific and irrelevant > for the DT description. > >> The w2sg0004-regulator approach just follows this principle. >> Anyone willing to control the power of the w2sg0004 can use this >> regulator interface. > > From a HW perspective your regulator "hides" the information, that > there is a device attached to the serial port and instead claims, > that a regulator is needed to make the serial port work. Yes, without this regulator the serial port does not work. It is IMHO more important than stating the obvious that a serial device is connected to a serial port. And if there is nothing to hide (the obvious serial interface wiring), why describe it at all? Anyways, in my proposal there will be a subnode of the uart, the one where it is specified that it should control the regulator of the w2sg. Basically, Neil’s proposal already covers this case. His bluetooth subnode just controls &vaux4 which turns on power for the w2cbw003 chip. So for my view it is not really understandable why one uart subnode can control a regulator, and the other can’t or shouldn’t and why this regulator function can’t be divided from the serial management into a regulator driver. > > Apart from that this interface is limited in its features. I'm > currently working on N900's bluetooth chip. This one needs to set a > gpio before data is sent data to the chip, has a reset gpio and > a gpio to wakeup the OMAP SoC from idle states to avoid data loss > on the UART. Yes, that looks equally complicated to solve if not even more than the w2sg chip. But what would you prefer: * extend the drivers/tty/slave/serial-power-manager.c to also cover your special case * instantiate a drivers/misc/n900-bluetooth-regulator.c and hook it up exactly like the vaux4 of the gta04 bluetooth chip? Just referencing a different regulator node? And as said I don’t mind if the regulator is a subnode of the omap3 serial. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi, On Fri, Mar 20, 2015 at 09:54:21AM +0100, Dr. H. Nikolaus Schaller wrote: > [...] > And we do not write a driver for the w2sg0004 but the regulator inside that > chip. DT describes the hardware structure and not the Linux driver structure. > You also won’t expect that the omap3 driver hides everything. You > expect that the twl4030 provides some regulators that can be enabled > by subsystems inside the omap3. And if I remember correctly there are > regulators inside the omap3 which have explicit regulator nodes in the DT. so let's have a look at twl regulators. They can be found below the twl node, so they will look similar to / -> omap3 -> i2c -> twl -> regulator So properly mapped to the w2sg0004 device this would put your regulator to / -> omap3 -> serial -> w2sg0004 -> regulator This will gain you nothing as far as I can tell. Please note that subdevices under the serial node are pretty useful, since then the kernel can e.g. automatically setup correct line disciplines for serial attached bluetooth chips and make bluetooth work out of the box. I am aware, that the Linux kernel has no such thing for serial attached GPS devices, but that's Linux specific and irrelevant for the DT description. > The w2sg0004-regulator approach just follows this principle. > Anyone willing to control the power of the w2sg0004 can use this > regulator interface. From a HW perspective your regulator "hides" the information, that there is a device attached to the serial port and instead claims, that a regulator is needed to make the serial port work. Apart from that this interface is limited in its features. I'm currently working on N900's bluetooth chip. This one needs to set a gpio before data is sent data to the chip, has a reset gpio and a gpio to wakeup the OMAP SoC from idle states to avoid data loss on the UART. -- Sebastian signature.asc Description: Digital signature
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi, Am 20.03.2015 um 09:43 schrieb NeilBrown : > On Fri, 20 Mar 2015 08:54:35 +0100 "Dr. H. Nikolaus Schaller" > wrote: > >> Hi Neil, >> >> Am 18.03.2015 um 06:58 schrieb NeilBrown : >> >>> 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". Then we should find a different word. > 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. Yes, it should - if necessary. > Surely you agree that there is a particular device that needs to be > controlled? No, my opinion is that a specific regulator should be controlled. > In that case there needs to be a node representing it and a > "compatible" string describing it. That is how “devicetree" works. For this there is the vdd-regulator = <®ulator> idiom and that is how “devicetree” works as well. > > >> >>> >>> 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, therefore our proposal is to make it a drivers/misc and not a drivers/regulator. But it has a regulator inside that can obviously be turned on or off. So I want to keep close to the logical energy flow. > 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...) We got a lot of support. The main opposition was about using a “virtual” gpio controller instead of a regulator API to turn the chip on and off as directed by the tty driver. And we do not write a driver for the w2sg0004 but the regulator inside that chip. You also won’t expect that the omap3 driver hides everything. You expect that the twl4030 provides some regulators that can be enabled by subsystems inside the omap3. And if I remember correctly there are regulators inside the omap3 which have explicit regulator nodes in the DT. The w2sg0004-regulator approach just follows this principle. Anyone willing to control the power of the w2sg0004 can use this regulator interface. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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" wrote: > Hi Neil, > > Am 18.03.2015 um 06:58 schrieb NeilBrown : > > > 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 pgp0ek3RG628N.pgp Description: OpenPGP digital signature
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Neil, Am 18.03.2015 um 06:58 schrieb NeilBrown : > 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. > 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. > > 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. Nikolaus > > Thanks for your review, > NeilBrown > > > --- > > NeilBrown (3): > TTY: use class_find_device to find port in uart_suspend/resume. > TTY: add support for tty_slave devices. > tty/slaves: add a driver to power on/off UART attached devices. > > > .../bindings/tty_slave/wi2wi,w2cbw003.txt | 19 + > .../bindings/tty_slave/wi2wi,w2sg0004.txt | 37 + > .../devicetree/bindings/vendor-prefixes.txt|1 > drivers/tty/Kconfig|1 > drivers/tty/Makefile |1 > drivers/tty/serial/serial_core.c | 21 - > drivers/tty/slave/Kconfig | 21 + > drivers/tty/slave/Makefile |4 > drivers/tty/slave/serial-power-manager.c | 510 > drivers/tty/slave/tty_slave_core.c | 136 + > drivers/tty/tty_io.c | 60 ++ > include/linux/tty.h|2 > include/linux/tty_slave.h | 26 + > 13 files changed, 813 insertions(+), 26 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt > create mode 100644 > Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt > create mode 100644 drivers/tty/slave/Kconfig > create mode 100644 drivers/tty/slave/Makefile > create mode 100644 drivers/tty/slave/serial-power-manager.c > create mode 100644 drivers/tty/slave/tty_slave_core.c > create mode 100644 include/linux/tty_slave.h > > -- > Signature > > ___ > Gta04-owner mailing list > gta04-ow...@goldelico.com > http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
