Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4
Hi Pavel, Am 28.08.2015 um 09:02 schrieb Pavel Machek : > Hi! > >> we (the developers of the hardware) have proposed an alternative >> approach to Neil’s implementation - for the same device and solving >> the same problem (notifying tty open/close and uart activity to the >> slave device driver), but differently. >> >> See: >> https://lkml.org/lkml/2015/6/28/91 >> >> Discussion has not yet settled on which approach is better. So your >> opinion of comparing both is welcome. > > Actually, yes, discussion has settled, agreeing that phandle reference > for the uart is a bad idea, Nikolaus just refuses to listen to anyone, no, I only refuse to listen to you. You are neither maintainer for any subsystem that is involved nor have you contributed technical arguments pro/con and it appears to me that you refuse to listen to my argumentation. > asking "device tree maintainer opinion", and then just simply ignoring > it when he does not like it, and then making promises he did not keep. Which promises did I not keep? Please be specific, instead of insulting. I bring up this alternative again, since I get the impression that most readers are simply not aware of *both* alternative proposals. > Please don't stall patches just because of that. Please provide better arguments and don’t spread FUD. Please have a look into our RFC implementation and study it carefully to learn why it is the better (IMHO more flexible, easier to maintain, more modular) approach. Even if you don’t like phandles. > > Best regards, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4
Hi Pavel, Am 28.08.2015 um 09:02 schrieb Pavel Machek pa...@ucw.cz: Hi! we (the developers of the hardware) have proposed an alternative approach to Neil’s implementation - for the same device and solving the same problem (notifying tty open/close and uart activity to the slave device driver), but differently. See: https://lkml.org/lkml/2015/6/28/91 Discussion has not yet settled on which approach is better. So your opinion of comparing both is welcome. Actually, yes, discussion has settled, agreeing that phandle reference for the uart is a bad idea, Nikolaus just refuses to listen to anyone, no, I only refuse to listen to you. You are neither maintainer for any subsystem that is involved nor have you contributed technical arguments pro/con and it appears to me that you refuse to listen to my argumentation. asking device tree maintainer opinion, and then just simply ignoring it when he does not like it, and then making promises he did not keep. Which promises did I not keep? Please be specific, instead of insulting. I bring up this alternative again, since I get the impression that most readers are simply not aware of *both* alternative proposals. Please don't stall patches just because of that. Please provide better arguments and don’t spread FUD. Please have a look into our RFC implementation and study it carefully to learn why it is the better (IMHO more flexible, easier to maintain, more modular) approach. Even if you don’t like phandles. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4
Hi Linus,
Am 12.08.2015 um 01:20 schrieb NeilBrown :
> On Fri, 7 Aug 2015 15:01:47 +0200 Linus Walleij
> wrote:
>
>> Hi Neil,
>>
>> first, this is a *VERY* interesting and much needed patch series,
>> I intend to look closer at it, and if possible test it with some
>> (heh) board file device. Would be happy of you put me on CC for these.
>>
>> On Mon, May 11, 2015 at 3:56 AM, NeilBrown wrote:
>>
>>> When a device is connected to a UART via RS-232 (or similar), there
>>> is a DTR line that can be used for power management, and other "modem
>>> control" lines.
>>>
>>> On an embedded board, it is very likely that there is no "DTR", and
>>> any power management need to be done using some completely separate
>>> mechanism.
>>>
>>> So these "slaves" are really just for devices permanently attached to
>>> UARTs without a full "RS-232" (or similar) connection. The driver
>>> does all the extra control beyond Tx/Rx.
>>
>> What is usually happening (and I have seen it in a few places) is that
>> the SoC has *one* fully featured RS232 with CTS/RTS and even
>> DTS,DCD,RI and other esoterica, which is intended to be connected to a
>> host serial port or so, for example if this SoC is to act as a modem
>> or a fax machine, or if it is to drive one.
>>
>> Then they often have a few more UART blocks, usually identical, which
>> only have RxD+TxD available, so they are "just" UARTs.
>>
>> To complicate things further, you may wonder what happened with
>> the CTS/RTS (etc) signals from the other blocks. Usually they are there
>> in the silicon but just routed to dead ends.
>>
>> To complicate it even further, usually all these pins are placed under
>> pin control multiplexing, so in an actual electronic design, the
>> system will mux out CTS/RTS (etc) from the fully featured RS232
>> blocks and only use them as UARTs anyways.
>>
>> Then there are those who created real simple RxD/TxD-only UARTs
>> ("yeah lets dump this RS232 legacy crap" / "yeah yeah")
>> and then realized they want to drive modems ("oh crap, it seemed
>> like a good idea at the time"). Then they usually take
>> two GPIO pins for CTS/RTS and drive them as GPIOs using
>> software and you have a cheap 4-line modem line. This is what
>> drivers/tty/serial/serial_mctrl_gpio.c is for if you wondered.
>>
>>> I've tested this set and it seems to work ... except that something
>>> is sadly broken with bluetooth support in 4.1-rc1 so I've only really
>>> tested the GPS driver. I guess it is time to rebase to -rc3.
>>
>> You have a hardware taget I see. Which one?
>
> GTA04 (www.gta04.org - openmoko successor).
>
> 3 uarts on OMAP3 are wired: one as RS-232 for console, one to bluetooth
> half of a wifi/bluetooth module, and one to a GPS.
>
> For the GPS, I just want to power on/off when the TTY is opened/closed,
> but the power-on sequence is non-trivial as both "turn on" and
> "turn-off' toggle the same line, so I need to be able to detect current
> state.
>
> For the bluetooth, the power is a (shared) regulator. As well as
> power-on when the TTY is opened, I'd like regulator to be turned of
> when I "hciconfig down" - even though the TTY is still open.
> I did a patch a while ago which hooked in to hci_uart_{open,close} to
> make this work, but it isn't a really good patch.
>
> It would be nice to hide the TTY from user-space in the bluetooth case,
> and have the "hciattach" happen in the kernel, but I think hciattach
> does extra initialisation...
>
> NeilBrown
we (the developers of the hardware) have proposed an alternative
approach to Neil’s implementation - for the same device and solving
the same problem (notifying tty open/close and uart activity to the
slave device driver), but differently.
See:
https://lkml.org/lkml/2015/6/28/91
Discussion has not yet settled on which approach is better. So your
opinion of comparing both is welcome.
BR,
Nikolaus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4
Hi Linus,
Am 12.08.2015 um 01:20 schrieb NeilBrown n...@brown.name:
On Fri, 7 Aug 2015 15:01:47 +0200 Linus Walleij
linus.wall...@linaro.org wrote:
Hi Neil,
first, this is a *VERY* interesting and much needed patch series,
I intend to look closer at it, and if possible test it with some
(heh) board file device. Would be happy of you put me on CC for these.
On Mon, May 11, 2015 at 3:56 AM, NeilBrown n...@brown.name wrote:
When a device is connected to a UART via RS-232 (or similar), there
is a DTR line that can be used for power management, and other modem
control lines.
On an embedded board, it is very likely that there is no DTR, and
any power management need to be done using some completely separate
mechanism.
So these slaves are really just for devices permanently attached to
UARTs without a full RS-232 (or similar) connection. The driver
does all the extra control beyond Tx/Rx.
What is usually happening (and I have seen it in a few places) is that
the SoC has *one* fully featured RS232 with CTS/RTS and even
DTS,DCD,RI and other esoterica, which is intended to be connected to a
host serial port or so, for example if this SoC is to act as a modem
or a fax machine, or if it is to drive one.
Then they often have a few more UART blocks, usually identical, which
only have RxD+TxD available, so they are just UARTs.
To complicate things further, you may wonder what happened with
the CTS/RTS (etc) signals from the other blocks. Usually they are there
in the silicon but just routed to dead ends.
To complicate it even further, usually all these pins are placed under
pin control multiplexing, so in an actual electronic design, the
system will mux out CTS/RTS (etc) from the fully featured RS232
blocks and only use them as UARTs anyways.
Then there are those who created real simple RxD/TxD-only UARTs
(yeah lets dump this RS232 legacy crap / yeah yeah)
and then realized they want to drive modems (oh crap, it seemed
like a good idea at the time). Then they usually take
two GPIO pins for CTS/RTS and drive them as GPIOs using
software and you have a cheap 4-line modem line. This is what
drivers/tty/serial/serial_mctrl_gpio.c is for if you wondered.
I've tested this set and it seems to work ... except that something
is sadly broken with bluetooth support in 4.1-rc1 so I've only really
tested the GPS driver. I guess it is time to rebase to -rc3.
You have a hardware taget I see. Which one?
GTA04 (www.gta04.org - openmoko successor).
3 uarts on OMAP3 are wired: one as RS-232 for console, one to bluetooth
half of a wifi/bluetooth module, and one to a GPS.
For the GPS, I just want to power on/off when the TTY is opened/closed,
but the power-on sequence is non-trivial as both turn on and
turn-off' toggle the same line, so I need to be able to detect current
state.
For the bluetooth, the power is a (shared) regulator. As well as
power-on when the TTY is opened, I'd like regulator to be turned of
when I hciconfig down - even though the TTY is still open.
I did a patch a while ago which hooked in to hci_uart_{open,close} to
make this work, but it isn't a really good patch.
It would be nice to hide the TTY from user-space in the bluetooth case,
and have the hciattach happen in the kernel, but I think hciattach
does extra initialisation...
NeilBrown
we (the developers of the hardware) have proposed an alternative
approach to Neil’s implementation - for the same device and solving
the same problem (notifying tty open/close and uart activity to the
slave device driver), but differently.
See:
https://lkml.org/lkml/2015/6/28/91
Discussion has not yet settled on which approach is better. So your
opinion of comparing both is welcome.
BR,
Nikolaus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: twl4030-vibra: Fix ERROR: Bad of_node_put() warning
Am 29.07.2015 um 19:26 schrieb Dmitry Torokhov : > On Tue, Jul 28, 2015 at 10:13:54PM -0500, Rob Herring wrote: >> On Tue, Jul 28, 2015 at 3:23 PM, Belisko Marek >> wrote: >>> Hi Dmitry, >>> >>> On Thu, Jul 23, 2015 at 10:53 PM, Dmitry Torokhov >>> wrote: On Thu, Jul 23, 2015 at 10:38:34PM +0200, Marek Belisko wrote: > Fix following: > [8.862274] ERROR: Bad of_node_put() on /ocp/i2c@4807/twl@48/audio > [8.869293] CPU: 0 PID: 1003 Comm: modprobe Not tainted > 4.2.0-rc2-letux+ #1175 > [8.876922] Hardware name: Generic OMAP36xx (Flattened Device Tree) > [8.883514] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [8.891693] [] (show_stack) from [] > (dump_stack+0x78/0x94) > [8.899322] [] (dump_stack) from [] > (kobject_release+0x68/0x7c) > [8.907409] [] (kobject_release) from [] > (twl4030_vibra_probe+0x74/0x188 [twl4030_vibra]) > [8.917877] [] (twl4030_vibra_probe [twl4030_vibra]) from > [] (platform_drv_probe+0x48/0x90) > [8.928497] [] (platform_drv_probe) from [] > (really_probe+0xd4/0x238) > [8.937103] [] (really_probe) from [] > (driver_probe_device+0x30/0x48) > [8.945678] [] (driver_probe_device) from [] > (__driver_attach+0x68/0x8c) > [8.954589] [] (__driver_attach) from [] > (bus_for_each_dev+0x50/0x84) > [8.963226] [] (bus_for_each_dev) from [] > (bus_add_driver+0xcc/0x1e4) > [8.971832] [] (bus_add_driver) from [] > (driver_register+0x9c/0xe0) > [8.980255] [] (driver_register) from [] > (do_one_initcall+0x100/0x1b8) > [8.988983] [] (do_one_initcall) from [] > (do_init_module+0x58/0x1c0) > [8.997497] [] (do_init_module) from [] > (SyS_init_module+0x54/0x64) > [9.005950] [] (SyS_init_module) from [] > (ret_fast_syscall+0x0/0x54) > [9.015838] input: twl4030:vibrator as > /devices/platform/6800.ocp/4807.i2c/i2c-0/0-0048/4807.i2c:twl@48:audio/input/input2 > > node passed to of_find_node_by_name is put inside that function and new > node > is returned if found. Free returned node not already freed node. Hmm, if of_find_node_by_name() "puts" passed in node should we not "get" it before calling of_find_node_by_name()? The node pointer in question is simply copied from parent device. >>> I'm not sure. what I can say is that I cannot see such error in 4.1 >>> but only in 4.2-rcx. >>> Adding Grant and Rob to CC, maybe they know what should be done and >>> why I see such error in 4.2-rcx. >> >> The problem was that node passed into of_find_node_by_name is the the >> starting point to search, but you should be doing the put on the >> returned node. So the patch below is correct. >> >> As far as why in 4.2, it seems you have OF_DYNAMIC enabled in your >> config either because you have DT unit test or overlays enabled. >> Overlays are now user enable-able in 4.2. > > Right, but the question was whether we should also "get" the node that > we are passing into of_find_node_by_name(), or, maybe better, stop > of_find_node_by_name() from "putting" the node that is passed in? It is > really surprising behavior. I agree that it is quite unexpected and would be much easier to understand if it would not put the node. But I guess it is intended to be a convenience to make it easier to walk down the tree, i.e. that you can simply write np = of_find_node_by_name(NULL, “level11”); np = of_find_node_by_name(np, “level2”); np = of_find_node_by_name(np, “level3”); Otherwise it would need some temporary variable and explicit calls to put the parent level after finding a child node. On the other hand greping for of_find_node_by_name returns many more calls with parent = NULL than others. So the put is ignored anyways. But it is a major change in semantics of a very low level function so it is easy to introduce regressions (especially in out-of-the tree drivers). Just my 2 cts, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: twl4030-vibra: Fix ERROR: Bad of_node_put() warning
Hi Tomi, Am 29.07.2015 um 07:47 schrieb Dr. H. Nikolaus Schaller : > Hi all, > > Am 29.07.2015 um 05:13 schrieb Rob Herring : > >> On Tue, Jul 28, 2015 at 3:23 PM, Belisko Marek >> wrote: >>> Hi Dmitry, >>> >>> On Thu, Jul 23, 2015 at 10:53 PM, Dmitry Torokhov >>> wrote: >>>> On Thu, Jul 23, 2015 at 10:38:34PM +0200, Marek Belisko wrote: >>>>> Fix following: >>>>> [8.862274] ERROR: Bad of_node_put() on /ocp/i2c@4807/twl@48/audio >>>>> [8.869293] CPU: 0 PID: 1003 Comm: modprobe Not tainted >>>>> 4.2.0-rc2-letux+ #1175 >>>>> [8.876922] Hardware name: Generic OMAP36xx (Flattened Device Tree) >>>>> [8.883514] [] (unwind_backtrace) from [] >>>>> (show_stack+0x10/0x14) >>>>> [8.891693] [] (show_stack) from [] >>>>> (dump_stack+0x78/0x94) >>>>> [8.899322] [] (dump_stack) from [] >>>>> (kobject_release+0x68/0x7c) >>>>> [8.907409] [] (kobject_release) from [] >>>>> (twl4030_vibra_probe+0x74/0x188 [twl4030_vibra]) >>>>> [8.917877] [] (twl4030_vibra_probe [twl4030_vibra]) from >>>>> [] (platform_drv_probe+0x48/0x90) >>>>> [8.928497] [] (platform_drv_probe) from [] >>>>> (really_probe+0xd4/0x238) >>>>> [8.937103] [] (really_probe) from [] >>>>> (driver_probe_device+0x30/0x48) >>>>> [8.945678] [] (driver_probe_device) from [] >>>>> (__driver_attach+0x68/0x8c) >>>>> [8.954589] [] (__driver_attach) from [] >>>>> (bus_for_each_dev+0x50/0x84) >>>>> [8.963226] [] (bus_for_each_dev) from [] >>>>> (bus_add_driver+0xcc/0x1e4) >>>>> [8.971832] [] (bus_add_driver) from [] >>>>> (driver_register+0x9c/0xe0) >>>>> [8.980255] [] (driver_register) from [] >>>>> (do_one_initcall+0x100/0x1b8) >>>>> [8.988983] [] (do_one_initcall) from [] >>>>> (do_init_module+0x58/0x1c0) >>>>> [8.997497] [] (do_init_module) from [] >>>>> (SyS_init_module+0x54/0x64) >>>>> [9.005950] [] (SyS_init_module) from [] >>>>> (ret_fast_syscall+0x0/0x54) >>>>> [9.015838] input: twl4030:vibrator as >>>>> /devices/platform/6800.ocp/4807.i2c/i2c-0/0-0048/4807.i2c:twl@48:audio/input/input2 >>>>> >>>>> node passed to of_find_node_by_name is put inside that function and new >>>>> node >>>>> is returned if found. Free returned node not already freed node. >>>> >>>> Hmm, if of_find_node_by_name() "puts" passed in node should we not "get" >>>> it before calling of_find_node_by_name()? The node pointer in question >>>> is simply copied from parent device. >>> I'm not sure. what I can say is that I cannot see such error in 4.1 >>> but only in 4.2-rcx. >>> Adding Grant and Rob to CC, maybe they know what should be done and >>> why I see such error in 4.2-rcx. >> >> The problem was that node passed into of_find_node_by_name is the the >> starting point to search, but you should be doing the put on the >> returned node. So the patch below is correct. > > Fine! > > We have a similar error on OMAP5 here: > > [ 11.027144] CPU: 1 PID: 6 Comm: kworker/u4:0 Not tainted 4.2.0-rc4-letux+ > #1187 > [ 11.034790] Hardware name: Generic OMAP5 (Flattened Device Tree) > [ 11.041077] Workqueue: deferwq deferred_probe_work_func > [ 11.046557] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 11.054663] [] (show_stack) from [] > (dump_stack+0x78/0x94) > [ 11.062224] [] (dump_stack) from [] > (kobject_release+0x68/0x7c) > [ 11.070234] [] (kobject_release) from [] > (omapdss_of_find_source_for_first_ep+0x58/0x74) > [ 11.080510] [] (omapdss_of_find_source_for_first_ep) from > [] (hdmic_probe+0xb4/0x22c [connector_hdmi]) > [ 11.092080] [] (hdmic_probe [connector_hdmi]) from [] > (platform_drv_probe+0x48/0x90) > [ 11.101997] [] (platform_drv_probe) from [] > (really_probe+0xd4/0x238) > [ 11.110556] [] (really_probe) from [] > (driver_probe_device+0x30/0x48) > [ 11.119108] [] (driver_probe_device) from [] > (bus_for_each_drv+0x4c/0x84) > [ 11.128023] [] (bus_for_each_drv) from [] > (__device_attach+0x70/0xd0) > [ 11.136579] [] (__device_attach) from [] > (bus_probe_device+0x28/0x84) > [ 11.145135] [] (bus_probe_device) fro
Re: [PATCH] input: twl4030-vibra: Fix ERROR: Bad of_node_put() warning
Am 29.07.2015 um 19:26 schrieb Dmitry Torokhov dmitry.torok...@gmail.com: On Tue, Jul 28, 2015 at 10:13:54PM -0500, Rob Herring wrote: On Tue, Jul 28, 2015 at 3:23 PM, Belisko Marek marek.beli...@gmail.com wrote: Hi Dmitry, On Thu, Jul 23, 2015 at 10:53 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Thu, Jul 23, 2015 at 10:38:34PM +0200, Marek Belisko wrote: Fix following: [8.862274] ERROR: Bad of_node_put() on /ocp/i2c@4807/twl@48/audio [8.869293] CPU: 0 PID: 1003 Comm: modprobe Not tainted 4.2.0-rc2-letux+ #1175 [8.876922] Hardware name: Generic OMAP36xx (Flattened Device Tree) [8.883514] [c00159e0] (unwind_backtrace) from [c0012488] (show_stack+0x10/0x14) [8.891693] [c0012488] (show_stack) from [c05cb810] (dump_stack+0x78/0x94) [8.899322] [c05cb810] (dump_stack) from [c02cfd5c] (kobject_release+0x68/0x7c) [8.907409] [c02cfd5c] (kobject_release) from [bf0040c4] (twl4030_vibra_probe+0x74/0x188 [twl4030_vibra]) [8.917877] [bf0040c4] (twl4030_vibra_probe [twl4030_vibra]) from [c03816ac] (platform_drv_probe+0x48/0x90) [8.928497] [c03816ac] (platform_drv_probe) from [c037feb4] (really_probe+0xd4/0x238) [8.937103] [c037feb4] (really_probe) from [c0380160] (driver_probe_device+0x30/0x48) [8.945678] [c0380160] (driver_probe_device) from [c03801e0] (__driver_attach+0x68/0x8c) [8.954589] [c03801e0] (__driver_attach) from [c037ea60] (bus_for_each_dev+0x50/0x84) [8.963226] [c037ea60] (bus_for_each_dev) from [c037f828] (bus_add_driver+0xcc/0x1e4) [8.971832] [c037f828] (bus_add_driver) from [c0380b60] (driver_register+0x9c/0xe0) [8.980255] [c0380b60] (driver_register) from [c00097e0] (do_one_initcall+0x100/0x1b8) [8.988983] [c00097e0] (do_one_initcall) from [c00b8008] (do_init_module+0x58/0x1c0) [8.997497] [c00b8008] (do_init_module) from [c00b8cac] (SyS_init_module+0x54/0x64) [9.005950] [c00b8cac] (SyS_init_module) from [c000ed20] (ret_fast_syscall+0x0/0x54) [9.015838] input: twl4030:vibrator as /devices/platform/6800.ocp/4807.i2c/i2c-0/0-0048/4807.i2c:twl@48:audio/input/input2 node passed to of_find_node_by_name is put inside that function and new node is returned if found. Free returned node not already freed node. Hmm, if of_find_node_by_name() puts passed in node should we not get it before calling of_find_node_by_name()? The node pointer in question is simply copied from parent device. I'm not sure. what I can say is that I cannot see such error in 4.1 but only in 4.2-rcx. Adding Grant and Rob to CC, maybe they know what should be done and why I see such error in 4.2-rcx. The problem was that node passed into of_find_node_by_name is the the starting point to search, but you should be doing the put on the returned node. So the patch below is correct. As far as why in 4.2, it seems you have OF_DYNAMIC enabled in your config either because you have DT unit test or overlays enabled. Overlays are now user enable-able in 4.2. Right, but the question was whether we should also get the node that we are passing into of_find_node_by_name(), or, maybe better, stop of_find_node_by_name() from putting the node that is passed in? It is really surprising behavior. I agree that it is quite unexpected and would be much easier to understand if it would not put the node. But I guess it is intended to be a convenience to make it easier to walk down the tree, i.e. that you can simply write np = of_find_node_by_name(NULL, “level11”); np = of_find_node_by_name(np, “level2”); np = of_find_node_by_name(np, “level3”); Otherwise it would need some temporary variable and explicit calls to put the parent level after finding a child node. On the other hand greping for of_find_node_by_name returns many more calls with parent = NULL than others. So the put is ignored anyways. But it is a major change in semantics of a very low level function so it is easy to introduce regressions (especially in out-of-the tree drivers). Just my 2 cts, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] input: twl4030-vibra: Fix ERROR: Bad of_node_put() warning
Hi Tomi, Am 29.07.2015 um 07:47 schrieb Dr. H. Nikolaus Schaller h...@goldelico.com: Hi all, Am 29.07.2015 um 05:13 schrieb Rob Herring robherri...@gmail.com: On Tue, Jul 28, 2015 at 3:23 PM, Belisko Marek marek.beli...@gmail.com wrote: Hi Dmitry, On Thu, Jul 23, 2015 at 10:53 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Thu, Jul 23, 2015 at 10:38:34PM +0200, Marek Belisko wrote: Fix following: [8.862274] ERROR: Bad of_node_put() on /ocp/i2c@4807/twl@48/audio [8.869293] CPU: 0 PID: 1003 Comm: modprobe Not tainted 4.2.0-rc2-letux+ #1175 [8.876922] Hardware name: Generic OMAP36xx (Flattened Device Tree) [8.883514] [c00159e0] (unwind_backtrace) from [c0012488] (show_stack+0x10/0x14) [8.891693] [c0012488] (show_stack) from [c05cb810] (dump_stack+0x78/0x94) [8.899322] [c05cb810] (dump_stack) from [c02cfd5c] (kobject_release+0x68/0x7c) [8.907409] [c02cfd5c] (kobject_release) from [bf0040c4] (twl4030_vibra_probe+0x74/0x188 [twl4030_vibra]) [8.917877] [bf0040c4] (twl4030_vibra_probe [twl4030_vibra]) from [c03816ac] (platform_drv_probe+0x48/0x90) [8.928497] [c03816ac] (platform_drv_probe) from [c037feb4] (really_probe+0xd4/0x238) [8.937103] [c037feb4] (really_probe) from [c0380160] (driver_probe_device+0x30/0x48) [8.945678] [c0380160] (driver_probe_device) from [c03801e0] (__driver_attach+0x68/0x8c) [8.954589] [c03801e0] (__driver_attach) from [c037ea60] (bus_for_each_dev+0x50/0x84) [8.963226] [c037ea60] (bus_for_each_dev) from [c037f828] (bus_add_driver+0xcc/0x1e4) [8.971832] [c037f828] (bus_add_driver) from [c0380b60] (driver_register+0x9c/0xe0) [8.980255] [c0380b60] (driver_register) from [c00097e0] (do_one_initcall+0x100/0x1b8) [8.988983] [c00097e0] (do_one_initcall) from [c00b8008] (do_init_module+0x58/0x1c0) [8.997497] [c00b8008] (do_init_module) from [c00b8cac] (SyS_init_module+0x54/0x64) [9.005950] [c00b8cac] (SyS_init_module) from [c000ed20] (ret_fast_syscall+0x0/0x54) [9.015838] input: twl4030:vibrator as /devices/platform/6800.ocp/4807.i2c/i2c-0/0-0048/4807.i2c:twl@48:audio/input/input2 node passed to of_find_node_by_name is put inside that function and new node is returned if found. Free returned node not already freed node. Hmm, if of_find_node_by_name() puts passed in node should we not get it before calling of_find_node_by_name()? The node pointer in question is simply copied from parent device. I'm not sure. what I can say is that I cannot see such error in 4.1 but only in 4.2-rcx. Adding Grant and Rob to CC, maybe they know what should be done and why I see such error in 4.2-rcx. The problem was that node passed into of_find_node_by_name is the the starting point to search, but you should be doing the put on the returned node. So the patch below is correct. Fine! We have a similar error on OMAP5 here: [ 11.027144] CPU: 1 PID: 6 Comm: kworker/u4:0 Not tainted 4.2.0-rc4-letux+ #1187 [ 11.034790] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 11.041077] Workqueue: deferwq deferred_probe_work_func [ 11.046557] [c0015a00] (unwind_backtrace) from [c00124a0] (show_stack+0x10/0x14) [ 11.054663] [c00124a0] (show_stack) from [c05cb694] (dump_stack+0x78/0x94) [ 11.062224] [c05cb694] (dump_stack) from [c02cfd5c] (kobject_release+0x68/0x7c) [ 11.070234] [c02cfd5c] (kobject_release) from [c03291d8] (omapdss_of_find_source_for_first_ep+0x58/0x74) [ 11.080510] [c03291d8] (omapdss_of_find_source_for_first_ep) from [bf089290] (hdmic_probe+0xb4/0x22c [connector_hdmi]) [ 11.092080] [bf089290] (hdmic_probe [connector_hdmi]) from [c0381490] (platform_drv_probe+0x48/0x90) [ 11.101997] [c0381490] (platform_drv_probe) from [c037fc98] (really_probe+0xd4/0x238) [ 11.110556] [c037fc98] (really_probe) from [c037ff44] (driver_probe_device+0x30/0x48) [ 11.119108] [c037ff44] (driver_probe_device) from [c037e7bc] (bus_for_each_drv+0x4c/0x84) [ 11.128023] [c037e7bc] (bus_for_each_drv) from [c037fe90] (__device_attach+0x70/0xd0) [ 11.136579] [c037fe90] (__device_attach) from [c037f3f8] (bus_probe_device+0x28/0x84) [ 11.145135] [c037f3f8] (bus_probe_device) from [c037f808] (deferred_probe_work_func+0x58/0x88) [ 11.154518] [c037f808] (deferred_probe_work_func) from [c0054ff0] (process_one_work+0x294/0x4a0) [ 11.164083] [c0054ff0] (process_one_work) from [c0055414] (worker_thread+0x1ec/0x2fc) [ 11.172641] [c0055414] (worker_thread) from [c005a3b4] (kthread+0xd4/0xe8) [ 11.180200] [c005a3b4] (kthread) from [c000edf8] (ret_from_fork+0x14/0x3c) So it looks as if there are more get/put mismatches in the drivers which are usually not visible. As far as why in 4.2, it seems you have OF_DYNAMIC enabled in your config either because you have DT unit test or overlays enabled. Overlays are now user enable-able in 4.2. Further analysis
Re: [PATCH] input: twl4030-vibra: Fix ERROR: Bad of_node_put() warning
Hi all, Am 29.07.2015 um 05:13 schrieb Rob Herring : > On Tue, Jul 28, 2015 at 3:23 PM, Belisko Marek > wrote: >> Hi Dmitry, >> >> On Thu, Jul 23, 2015 at 10:53 PM, Dmitry Torokhov >> wrote: >>> On Thu, Jul 23, 2015 at 10:38:34PM +0200, Marek Belisko wrote: Fix following: [8.862274] ERROR: Bad of_node_put() on /ocp/i2c@4807/twl@48/audio [8.869293] CPU: 0 PID: 1003 Comm: modprobe Not tainted 4.2.0-rc2-letux+ #1175 [8.876922] Hardware name: Generic OMAP36xx (Flattened Device Tree) [8.883514] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [8.891693] [] (show_stack) from [] (dump_stack+0x78/0x94) [8.899322] [] (dump_stack) from [] (kobject_release+0x68/0x7c) [8.907409] [] (kobject_release) from [] (twl4030_vibra_probe+0x74/0x188 [twl4030_vibra]) [8.917877] [] (twl4030_vibra_probe [twl4030_vibra]) from [] (platform_drv_probe+0x48/0x90) [8.928497] [] (platform_drv_probe) from [] (really_probe+0xd4/0x238) [8.937103] [] (really_probe) from [] (driver_probe_device+0x30/0x48) [8.945678] [] (driver_probe_device) from [] (__driver_attach+0x68/0x8c) [8.954589] [] (__driver_attach) from [] (bus_for_each_dev+0x50/0x84) [8.963226] [] (bus_for_each_dev) from [] (bus_add_driver+0xcc/0x1e4) [8.971832] [] (bus_add_driver) from [] (driver_register+0x9c/0xe0) [8.980255] [] (driver_register) from [] (do_one_initcall+0x100/0x1b8) [8.988983] [] (do_one_initcall) from [] (do_init_module+0x58/0x1c0) [8.997497] [] (do_init_module) from [] (SyS_init_module+0x54/0x64) [9.005950] [] (SyS_init_module) from [] (ret_fast_syscall+0x0/0x54) [9.015838] input: twl4030:vibrator as /devices/platform/6800.ocp/4807.i2c/i2c-0/0-0048/4807.i2c:twl@48:audio/input/input2 node passed to of_find_node_by_name is put inside that function and new node is returned if found. Free returned node not already freed node. >>> >>> Hmm, if of_find_node_by_name() "puts" passed in node should we not "get" >>> it before calling of_find_node_by_name()? The node pointer in question >>> is simply copied from parent device. >> I'm not sure. what I can say is that I cannot see such error in 4.1 >> but only in 4.2-rcx. >> Adding Grant and Rob to CC, maybe they know what should be done and >> why I see such error in 4.2-rcx. > > The problem was that node passed into of_find_node_by_name is the the > starting point to search, but you should be doing the put on the > returned node. So the patch below is correct. Fine! We have a similar error on OMAP5 here: [ 11.027144] CPU: 1 PID: 6 Comm: kworker/u4:0 Not tainted 4.2.0-rc4-letux+ #1187 [ 11.034790] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 11.041077] Workqueue: deferwq deferred_probe_work_func [ 11.046557] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 11.054663] [] (show_stack) from [] (dump_stack+0x78/0x94) [ 11.062224] [] (dump_stack) from [] (kobject_release+0x68/0x7c) [ 11.070234] [] (kobject_release) from [] (omapdss_of_find_source_for_first_ep+0x58/0x74) [ 11.080510] [] (omapdss_of_find_source_for_first_ep) from [] (hdmic_probe+0xb4/0x22c [connector_hdmi]) [ 11.092080] [] (hdmic_probe [connector_hdmi]) from [] (platform_drv_probe+0x48/0x90) [ 11.101997] [] (platform_drv_probe) from [] (really_probe+0xd4/0x238) [ 11.110556] [] (really_probe) from [] (driver_probe_device+0x30/0x48) [ 11.119108] [] (driver_probe_device) from [] (bus_for_each_drv+0x4c/0x84) [ 11.128023] [] (bus_for_each_drv) from [] (__device_attach+0x70/0xd0) [ 11.136579] [] (__device_attach) from [] (bus_probe_device+0x28/0x84) [ 11.145135] [] (bus_probe_device) from [] (deferred_probe_work_func+0x58/0x88) [ 11.154518] [] (deferred_probe_work_func) from [] (process_one_work+0x294/0x4a0) [ 11.164083] [] (process_one_work) from [] (worker_thread+0x1ec/0x2fc) [ 11.172641] [] (worker_thread) from [] (kthread+0xd4/0xe8) [ 11.180200] [] (kthread) from [] (ret_from_fork+0x14/0x3c) So it looks as if there are more get/put mismatches in the drivers which are usually not visible. > > As far as why in 4.2, it seems you have OF_DYNAMIC enabled in your > config either because you have DT unit test or overlays enabled. > Overlays are now user enable-able in 4.2. Further analysis turns out that we recently have enabled DRM_TILCDC_SLAVE_COMPAT=y which we need to make our uImage additionally support the BeagleBone Black with LDC panel (as mandated by arch/arm/boot/dts/am335x-boneblack.dts using “ti,tilcdc,slave”). This automatically enables OF_OVERLAY which enables OF_DYNAMIC. Obviously this now has unexpected side-effects on other systems with universal kernels configured to support both, beaglebone and non-beaglebone devices. So what is wrong? The sequence
Re: [PATCH] input: twl4030-vibra: Fix ERROR: Bad of_node_put() warning
Hi all, Am 29.07.2015 um 05:13 schrieb Rob Herring robherri...@gmail.com: On Tue, Jul 28, 2015 at 3:23 PM, Belisko Marek marek.beli...@gmail.com wrote: Hi Dmitry, On Thu, Jul 23, 2015 at 10:53 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Thu, Jul 23, 2015 at 10:38:34PM +0200, Marek Belisko wrote: Fix following: [8.862274] ERROR: Bad of_node_put() on /ocp/i2c@4807/twl@48/audio [8.869293] CPU: 0 PID: 1003 Comm: modprobe Not tainted 4.2.0-rc2-letux+ #1175 [8.876922] Hardware name: Generic OMAP36xx (Flattened Device Tree) [8.883514] [c00159e0] (unwind_backtrace) from [c0012488] (show_stack+0x10/0x14) [8.891693] [c0012488] (show_stack) from [c05cb810] (dump_stack+0x78/0x94) [8.899322] [c05cb810] (dump_stack) from [c02cfd5c] (kobject_release+0x68/0x7c) [8.907409] [c02cfd5c] (kobject_release) from [bf0040c4] (twl4030_vibra_probe+0x74/0x188 [twl4030_vibra]) [8.917877] [bf0040c4] (twl4030_vibra_probe [twl4030_vibra]) from [c03816ac] (platform_drv_probe+0x48/0x90) [8.928497] [c03816ac] (platform_drv_probe) from [c037feb4] (really_probe+0xd4/0x238) [8.937103] [c037feb4] (really_probe) from [c0380160] (driver_probe_device+0x30/0x48) [8.945678] [c0380160] (driver_probe_device) from [c03801e0] (__driver_attach+0x68/0x8c) [8.954589] [c03801e0] (__driver_attach) from [c037ea60] (bus_for_each_dev+0x50/0x84) [8.963226] [c037ea60] (bus_for_each_dev) from [c037f828] (bus_add_driver+0xcc/0x1e4) [8.971832] [c037f828] (bus_add_driver) from [c0380b60] (driver_register+0x9c/0xe0) [8.980255] [c0380b60] (driver_register) from [c00097e0] (do_one_initcall+0x100/0x1b8) [8.988983] [c00097e0] (do_one_initcall) from [c00b8008] (do_init_module+0x58/0x1c0) [8.997497] [c00b8008] (do_init_module) from [c00b8cac] (SyS_init_module+0x54/0x64) [9.005950] [c00b8cac] (SyS_init_module) from [c000ed20] (ret_fast_syscall+0x0/0x54) [9.015838] input: twl4030:vibrator as /devices/platform/6800.ocp/4807.i2c/i2c-0/0-0048/4807.i2c:twl@48:audio/input/input2 node passed to of_find_node_by_name is put inside that function and new node is returned if found. Free returned node not already freed node. Hmm, if of_find_node_by_name() puts passed in node should we not get it before calling of_find_node_by_name()? The node pointer in question is simply copied from parent device. I'm not sure. what I can say is that I cannot see such error in 4.1 but only in 4.2-rcx. Adding Grant and Rob to CC, maybe they know what should be done and why I see such error in 4.2-rcx. The problem was that node passed into of_find_node_by_name is the the starting point to search, but you should be doing the put on the returned node. So the patch below is correct. Fine! We have a similar error on OMAP5 here: [ 11.027144] CPU: 1 PID: 6 Comm: kworker/u4:0 Not tainted 4.2.0-rc4-letux+ #1187 [ 11.034790] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 11.041077] Workqueue: deferwq deferred_probe_work_func [ 11.046557] [c0015a00] (unwind_backtrace) from [c00124a0] (show_stack+0x10/0x14) [ 11.054663] [c00124a0] (show_stack) from [c05cb694] (dump_stack+0x78/0x94) [ 11.062224] [c05cb694] (dump_stack) from [c02cfd5c] (kobject_release+0x68/0x7c) [ 11.070234] [c02cfd5c] (kobject_release) from [c03291d8] (omapdss_of_find_source_for_first_ep+0x58/0x74) [ 11.080510] [c03291d8] (omapdss_of_find_source_for_first_ep) from [bf089290] (hdmic_probe+0xb4/0x22c [connector_hdmi]) [ 11.092080] [bf089290] (hdmic_probe [connector_hdmi]) from [c0381490] (platform_drv_probe+0x48/0x90) [ 11.101997] [c0381490] (platform_drv_probe) from [c037fc98] (really_probe+0xd4/0x238) [ 11.110556] [c037fc98] (really_probe) from [c037ff44] (driver_probe_device+0x30/0x48) [ 11.119108] [c037ff44] (driver_probe_device) from [c037e7bc] (bus_for_each_drv+0x4c/0x84) [ 11.128023] [c037e7bc] (bus_for_each_drv) from [c037fe90] (__device_attach+0x70/0xd0) [ 11.136579] [c037fe90] (__device_attach) from [c037f3f8] (bus_probe_device+0x28/0x84) [ 11.145135] [c037f3f8] (bus_probe_device) from [c037f808] (deferred_probe_work_func+0x58/0x88) [ 11.154518] [c037f808] (deferred_probe_work_func) from [c0054ff0] (process_one_work+0x294/0x4a0) [ 11.164083] [c0054ff0] (process_one_work) from [c0055414] (worker_thread+0x1ec/0x2fc) [ 11.172641] [c0055414] (worker_thread) from [c005a3b4] (kthread+0xd4/0xe8) [ 11.180200] [c005a3b4] (kthread) from [c000edf8] (ret_from_fork+0x14/0x3c) So it looks as if there are more get/put mismatches in the drivers which are usually not visible. As far as why in 4.2, it seems you have OF_DYNAMIC enabled in your config either because you have DT unit test or overlays enabled. Overlays are now user enable-able in 4.2. Further analysis turns out that we recently have enabled DRM_TILCDC_SLAVE_COMPAT=y which we need to make our uImage additionally support the BeagleBone
Re: [PATCH RFC v2 1/3] tty: serial core: provide method to search uart by phandle
Hi,
Am 01.07.2015 um 20:16 schrieb Rob Herring :
> On Sun, Jun 28, 2015 at 2:46 PM, Marek Belisko wrote:
>> From: "H. Nikolaus Schaller"
>>
>> 1. add registered uart_ports to a search list
>> 2. provide a function to search an uart_port by phandle. This copies the
>> mechanism how devm_usb_get_phy_by_phandle() works
>
> How does this relate to Neil's tty/uart slaves series?
we had questioned the approach of interpreting uarts as a degenerated
single-client
bus and therefore handling uart slave devices by subnodes.
Rather than having a „UART n is connected to device“ subnode, we think that a
„this device is connected to UART n“ phandle is the most elegant and flexible
way to implement it. Like it is for PHY relations within the USB subsystem.
After a long theoretical discussion we were asked to submit code to better allow
to compare both approaches.
Here it is.
So common is the problem that we want to solve. Different is the solution.
Both implementations are tested to work on the GTA04 hardware.
>
>> Signed-off-by: H. Nikolaus Schaller
>> Signed-off-by: Marek Belisko
>> ---
>> Documentation/serial/slaves.txt | 36 ++
>
> You need to split this into DT binding and whatever kernel specific
> documentation you want. My comment below apply to what goes in the
> binding doc.
This driver does not define any specific bindings for the slave device,
therefore
we have not provided a bindings document. It is up to the slave driver to
provide
one.
This driver just provides means that a slave driver can interact with the
tty/serial
driver.
Bindings for a specific slave device are defined in our
[PATCH RFC v2 3/3] misc: Add w2g0004 gps receiver driver
../devicetree/bindings/misc/wi2wi,w2sg0004.txt
>
>> drivers/tty/serial/serial_core.c | 103
>> +++
>> include/linux/serial_core.h | 10
>> 3 files changed, 149 insertions(+)
>> create mode 100644 Documentation/serial/slaves.txt
>>
>> diff --git a/Documentation/serial/slaves.txt
>> b/Documentation/serial/slaves.txt
>> new file mode 100644
>> index 000..6f8d44d
>> --- /dev/null
>> +++ b/Documentation/serial/slaves.txt
>> @@ -0,0 +1,36 @@
>> +UART slave device support
>> +
>> +A remote device connected to a RS232 interface is usually power controlled
>> by the DTR line.
>> +The DTR line is managed automatically by the UART driver for open() and
>> close() syscalls
>> +and on demand by tcsetattr().
>> +
>> +With embedded devices, the serial peripheral might be directly and always
>> connected to the UART
>> +and there might be no physical DTR line involved. Power control (on/off)
>> has to be done by some
>> +chip specific device driver (which we call "UART slave") through some
>> mechanisms (I2C, GPIOs etc.)
>> +not related to the serial interface. Some devices do not explicitly tell
>> their power state except
>> +by sending or not sending data to the UART. In such a case the device
>> driver must be able to monitor
>> +data activity. The role of the device driver is to encapsulate such power
>> control in a single place.
>> +
>> +This patch series allows to support such drivers by providing:
>> +* a mechanism that a slave driver can identify the UART instance it is
>> connected to
>> +* a mechanism that UART slave drivers can register to be notified
>> +* notfications for DTR (and other modem control) state changes
>
> This has nothing to do with the binding really, but is rather a Linux
> driver feature.
Yes, we want to describe the linux driver features here.
>
>> +* notifications that the UART has received some data from the UART
>> +
>> +A slave device simply adds a phandle reference to the UART it is connected
>> to, e.g.
>
> By default I think this should be a sub-node of the uart.
We want to show with this implementation that uart-subnodes would be the wrong
way to go.
> There are
> more complicated cases of combo devices which we may need to support
> with phandles, but by default we should use sub-nodes to describe
> connections.
There can be serial devices which are power-controlled by I2C and then
we would have a problem to describe the connection as both I2C and UART
subnodes.
For us the "main interface“ of a chip is the one that allows to turn the device
on and off. And not the one that carries data provided by/to user space
(„payload“).
This is rarely the serial data stream. Hence describing the subdevice by a
subnode of the uart is describing something different from what we need.
>
>> +
>> + gps {
>> + compatible = "wi2wi,w2sg0004";
>> + uart = <>;
>
> What if you have a device with 2 uart connections? Do you have 2 items
> in the list or do multiple "-uart" entries? The former is
> probably sufficient and easier to parse.
It is up to the subdevice driver how it is implemented. So view this as an
example
that has only one uart connection.
For two uart connections you can choose either of your proposals
Re: [PATCH RFC v2 1/3] tty: serial core: provide method to search uart by phandle
Hi,
Am 01.07.2015 um 20:16 schrieb Rob Herring robherri...@gmail.com:
On Sun, Jun 28, 2015 at 2:46 PM, Marek Belisko ma...@goldelico.com wrote:
From: H. Nikolaus Schaller h...@goldelico.com
1. add registered uart_ports to a search list
2. provide a function to search an uart_port by phandle. This copies the
mechanism how devm_usb_get_phy_by_phandle() works
How does this relate to Neil's tty/uart slaves series?
we had questioned the approach of interpreting uarts as a degenerated
single-client
bus and therefore handling uart slave devices by subnodes.
Rather than having a „UART n is connected to device“ subnode, we think that a
„this device is connected to UART n“ phandle is the most elegant and flexible
way to implement it. Like it is for PHY relations within the USB subsystem.
After a long theoretical discussion we were asked to submit code to better allow
to compare both approaches.
Here it is.
So common is the problem that we want to solve. Different is the solution.
Both implementations are tested to work on the GTA04 hardware.
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
Signed-off-by: Marek Belisko ma...@goldelico.com
---
Documentation/serial/slaves.txt | 36 ++
You need to split this into DT binding and whatever kernel specific
documentation you want. My comment below apply to what goes in the
binding doc.
This driver does not define any specific bindings for the slave device,
therefore
we have not provided a bindings document. It is up to the slave driver to
provide
one.
This driver just provides means that a slave driver can interact with the
tty/serial
driver.
Bindings for a specific slave device are defined in our
[PATCH RFC v2 3/3] misc: Add w2g0004 gps receiver driver
../devicetree/bindings/misc/wi2wi,w2sg0004.txt
drivers/tty/serial/serial_core.c | 103
+++
include/linux/serial_core.h | 10
3 files changed, 149 insertions(+)
create mode 100644 Documentation/serial/slaves.txt
diff --git a/Documentation/serial/slaves.txt
b/Documentation/serial/slaves.txt
new file mode 100644
index 000..6f8d44d
--- /dev/null
+++ b/Documentation/serial/slaves.txt
@@ -0,0 +1,36 @@
+UART slave device support
+
+A remote device connected to a RS232 interface is usually power controlled
by the DTR line.
+The DTR line is managed automatically by the UART driver for open() and
close() syscalls
+and on demand by tcsetattr().
+
+With embedded devices, the serial peripheral might be directly and always
connected to the UART
+and there might be no physical DTR line involved. Power control (on/off)
has to be done by some
+chip specific device driver (which we call UART slave) through some
mechanisms (I2C, GPIOs etc.)
+not related to the serial interface. Some devices do not explicitly tell
their power state except
+by sending or not sending data to the UART. In such a case the device
driver must be able to monitor
+data activity. The role of the device driver is to encapsulate such power
control in a single place.
+
+This patch series allows to support such drivers by providing:
+* a mechanism that a slave driver can identify the UART instance it is
connected to
+* a mechanism that UART slave drivers can register to be notified
+* notfications for DTR (and other modem control) state changes
This has nothing to do with the binding really, but is rather a Linux
driver feature.
Yes, we want to describe the linux driver features here.
+* notifications that the UART has received some data from the UART
+
+A slave device simply adds a phandle reference to the UART it is connected
to, e.g.
By default I think this should be a sub-node of the uart.
We want to show with this implementation that uart-subnodes would be the wrong
way to go.
There are
more complicated cases of combo devices which we may need to support
with phandles, but by default we should use sub-nodes to describe
connections.
There can be serial devices which are power-controlled by I2C and then
we would have a problem to describe the connection as both I2C and UART
subnodes.
For us the main interface“ of a chip is the one that allows to turn the device
on and off. And not the one that carries data provided by/to user space
(„payload“).
This is rarely the serial data stream. Hence describing the subdevice by a
subnode of the uart is describing something different from what we need.
+
+ gps {
+ compatible = wi2wi,w2sg0004;
+ uart = uart1;
What if you have a device with 2 uart connections? Do you have 2 items
in the list or do multiple name-uart entries? The former is
probably sufficient and easier to parse.
It is up to the subdevice driver how it is implemented. So view this as an
example
that has only one uart connection.
For two uart connections you can choose either of your proposals since the
translator
function has both a
Re: [PATCH RFC v2 3/3] misc: Add w2g0004 gps receiver driver
Hi,
thanks for the valid and very valuable comments!
We will integrate them into RFC v3.
BR,
Nikolaus
Am 30.06.2015 um 10:23 schrieb Sergei Zviagintsev :
> Hi,
>
> I left some comments below.
>
> On Sun, Jun 28, 2015 at 09:46:26PM +0200, Marek Belisko wrote:
>> From: "H. Nikolaus Schaller"
>>
>> Add driver for Wi2Wi w2g004 GPS module connected through uart. Use uart
>> slave + notification hooks to glue with tty.
>>
>> Signed-off-by: H. Nikolaus Schaller
>> Signed-off-by: Marek Belisko
>> ---
>> .../devicetree/bindings/misc/wi2wi,w2sg0004.txt| 18 +
>> drivers/misc/Kconfig | 18 +
>> drivers/misc/Makefile | 1 +
>> drivers/misc/w2sg0004.c| 436
>> +
>> include/linux/w2sg0004.h | 28 ++
>> 5 files changed, 501 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
>> create mode 100644 drivers/misc/w2sg0004.c
>> create mode 100644 include/linux/w2sg0004.h
>>
>> diff --git a/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
>> b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
>> new file mode 100644
>> index 000..ef0d6d5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
>> @@ -0,0 +1,18 @@
>> +Wi2Wi GPS module connected through UART
>> +
>> +Required properties:
>> +- compatible: wi2wi,w2sg0004 or wi2wi,w2sg0084
>> +- on-off-gpio: the GPIO that controls the module's on-off toggle input
>> +- uart: the uart we are connected to (provides DTR for power control)
>> +
>> +Optional properties:
>> +- lna-suppy: an (optional) LNA regulator that is enabled together with the
>> GPS receiver
>> +
>> +example:
>> +
>> +gps_receiver: w2sg0004 {
>> +compatible = "wi2wi,w2sg0004";
>> +lna-supply = <>; /* LNA regulator */
>> +on-off-gpio = < 17 0>;/* GPIO_145: trigger
>> for turning on/off w2sg0004 */
>> +uart = <>;/* we are a slave of uart1 */
>> +}
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>> index 42c3852..952add4 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -527,4 +527,22 @@ source "drivers/misc/mic/Kconfig"
>> source "drivers/misc/genwqe/Kconfig"
>> source "drivers/misc/echo/Kconfig"
>> source "drivers/misc/cxl/Kconfig"
>> +
>> +menu "GTA04 misc hardware support"
>> +
>> +config W2SG0004
>> +tristate "W2SG0004 on/off control"
>> +depends on GPIOLIB
>> +help
>> + Enable on/off control of W2SG0004 GPS using a tty slave to
>> + to allow powering up if the /dev/tty$n is opened.
>> + It also provides a rfkill gps node to control the LNA power.
>> +
>> +config W2SG0004_DEBUG
>> +bool "W2SG0004 on/off debugging"
>> +depends on W2SG0004
>> +help
>> + Enable driver debugging mode of W2SG0004 GPS.
>> +
>> +endmenu
>> endmenu
>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>> index d056fb7..3bc67c7 100644
>> --- a/drivers/misc/Makefile
>> +++ b/drivers/misc/Makefile
>> @@ -53,5 +53,6 @@ obj-$(CONFIG_SRAM) += sram.o
>> obj-y+= mic/
>> obj-$(CONFIG_GENWQE) += genwqe/
>> obj-$(CONFIG_ECHO) += echo/
>> +obj-$(CONFIG_W2SG0004) += w2sg0004.o
>> obj-$(CONFIG_VEXPRESS_SYSCFG)+= vexpress-syscfg.o
>> obj-$(CONFIG_CXL_BASE) += cxl/
>> diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
>> new file mode 100644
>> index 000..c5f0f7b
>> --- /dev/null
>> +++ b/drivers/misc/w2sg0004.c
>> @@ -0,0 +1,436 @@
>> +/*
>> + * w2sg0004.c
>> + * Driver for power controlling the w2sg0004/w2sg0084 GPS receiver.
>> + *
>> + * This receiver has an ON/OFF pin which must be toggled to
>> + * turn the device 'on' of 'off'. A high->low->high toggle
>> + * will switch the device on if it is off, and off if it is on.
>> + *
>> + * To enable receiving on/off requests we register with the
>> + * UART power management notifications.
>> + *
>> + * It is not possible to directly detect the state of the device.
>> + * However when it is on it will send characters on a UART line
>> + * regularly.
>> + *
>> + * To detect that the power state is out of sync (e.g. if GPS
>> + * was enabled before a reboot), we register for UART data received
>> + * notifications.
>> + *
>> + * In addition we register as a rfkill client so that we can
>> + * control the LNA power.
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#ifdef CONFIG_W2SG0004_DEBUG
>> +#undef pr_debug
>> +#define pr_debug printk
>> +#endif
>> +
>> +/*
>> + * There seems to be restrictions on how quickly we can toggle the
>> + * on/off line. data sheets says "two rtc ticks",
Re: [PATCH RFC v2 3/3] misc: Add w2g0004 gps receiver driver
Hi,
thanks for the valid and very valuable comments!
We will integrate them into RFC v3.
BR,
Nikolaus
Am 30.06.2015 um 10:23 schrieb Sergei Zviagintsev ser...@s15v.net:
Hi,
I left some comments below.
On Sun, Jun 28, 2015 at 09:46:26PM +0200, Marek Belisko wrote:
From: H. Nikolaus Schaller h...@goldelico.com
Add driver for Wi2Wi w2g004 GPS module connected through uart. Use uart
slave + notification hooks to glue with tty.
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
Signed-off-by: Marek Belisko ma...@goldelico.com
---
.../devicetree/bindings/misc/wi2wi,w2sg0004.txt| 18 +
drivers/misc/Kconfig | 18 +
drivers/misc/Makefile | 1 +
drivers/misc/w2sg0004.c| 436
+
include/linux/w2sg0004.h | 28 ++
5 files changed, 501 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
create mode 100644 drivers/misc/w2sg0004.c
create mode 100644 include/linux/w2sg0004.h
diff --git a/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
new file mode 100644
index 000..ef0d6d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/wi2wi,w2sg0004.txt
@@ -0,0 +1,18 @@
+Wi2Wi GPS module connected through UART
+
+Required properties:
+- compatible: wi2wi,w2sg0004 or wi2wi,w2sg0084
+- on-off-gpio: the GPIO that controls the module's on-off toggle input
+- uart: the uart we are connected to (provides DTR for power control)
+
+Optional properties:
+- lna-suppy: an (optional) LNA regulator that is enabled together with the
GPS receiver
+
+example:
+
+gps_receiver: w2sg0004 {
+compatible = wi2wi,w2sg0004;
+lna-supply = vsim; /* LNA regulator */
+on-off-gpio = gpio5 17 0;/* GPIO_145: trigger
for turning on/off w2sg0004 */
+uart = uart1;/* we are a slave of uart1 */
+}
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 42c3852..952add4 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -527,4 +527,22 @@ source drivers/misc/mic/Kconfig
source drivers/misc/genwqe/Kconfig
source drivers/misc/echo/Kconfig
source drivers/misc/cxl/Kconfig
+
+menu GTA04 misc hardware support
+
+config W2SG0004
+tristate W2SG0004 on/off control
+depends on GPIOLIB
+help
+ Enable on/off control of W2SG0004 GPS using a tty slave to
+ to allow powering up if the /dev/tty$n is opened.
+ It also provides a rfkill gps node to control the LNA power.
+
+config W2SG0004_DEBUG
+bool W2SG0004 on/off debugging
+depends on W2SG0004
+help
+ Enable driver debugging mode of W2SG0004 GPS.
+
+endmenu
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d056fb7..3bc67c7 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,5 +53,6 @@ obj-$(CONFIG_SRAM) += sram.o
obj-y+= mic/
obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
+obj-$(CONFIG_W2SG0004) += w2sg0004.o
obj-$(CONFIG_VEXPRESS_SYSCFG)+= vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
diff --git a/drivers/misc/w2sg0004.c b/drivers/misc/w2sg0004.c
new file mode 100644
index 000..c5f0f7b
--- /dev/null
+++ b/drivers/misc/w2sg0004.c
@@ -0,0 +1,436 @@
+/*
+ * w2sg0004.c
+ * Driver for power controlling the w2sg0004/w2sg0084 GPS receiver.
+ *
+ * This receiver has an ON/OFF pin which must be toggled to
+ * turn the device 'on' of 'off'. A high-low-high toggle
+ * will switch the device on if it is off, and off if it is on.
+ *
+ * To enable receiving on/off requests we register with the
+ * UART power management notifications.
+ *
+ * It is not possible to directly detect the state of the device.
+ * However when it is on it will send characters on a UART line
+ * regularly.
+ *
+ * To detect that the power state is out of sync (e.g. if GPS
+ * was enabled before a reboot), we register for UART data received
+ * notifications.
+ *
+ * In addition we register as a rfkill client so that we can
+ * control the LNA power.
+ *
+ */
+
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/sched.h
+#include linux/irq.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/delay.h
+#include linux/of.h
+#include linux/of_irq.h
+#include linux/of_gpio.h
+#include linux/platform_device.h
+#include linux/w2sg0004.h
+#include linux/workqueue.h
+#include linux/rfkill.h
+#include linux/serial_core.h
+
+#ifdef CONFIG_W2SG0004_DEBUG
+#undef pr_debug
+#define pr_debug printk
+#endif
+
+/*
+ * There seems to be restrictions on how quickly we can toggle the
+ * on/off line. data sheets says two rtc ticks, whatever
Re: [PATCH RFC v2 2/3] tty: serial_core: Add hooks for uart slave drivers
Hi,
thanks again.
Am 28.06.2015 um 23:51 schrieb Sergei Zviagintsev :
> Hi,
>
> Some minor comments below.
>
> On Sun, Jun 28, 2015 at 09:46:25PM +0200, Marek Belisko wrote:
>> From: "H. Nikolaus Schaller"
>>
>> 1. allow drivers to get notified in mctrl changes
>> 2. allow drivers to get notified on rx data (indicating to the driver that
>> the connected chip is active)
>>
>> Signed-off-by: H. Nikolaus Schaller
>> Signed-off-by: Marek Belisko
>> ---
>> drivers/tty/serial/serial_core.c | 102
>> +--
>> include/linux/serial_core.h | 11 -
>> 2 files changed, 107 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/tty/serial/serial_core.c
>> b/drivers/tty/serial/serial_core.c
>> index ad61441..c8910c4 100644
>> --- a/drivers/tty/serial/serial_core.c
>> +++ b/drivers/tty/serial/serial_core.c
>> @@ -163,6 +163,84 @@ err0:
>> }
>> EXPORT_SYMBOL_GPL(devm_serial_get_uart_by_phandle);
>>
>> +void uart_register_slave(struct uart_port *uport, void *slave)
>> +{
>> +if (!slave) {
>> +uart_register_mctrl_notification(uport, NULL);
>> +uart_register_rx_notification(uport, NULL, NULL);
>> +}
>> +uport->slave = slave;
>> +}
>> +
>> +void uart_register_mctrl_notification(struct uart_port *uport, int
>> (*function)(void *slave, int state))
>> +{
>> +uport->mctrl_notification = function;
>> +}
>> +
>> +static int uart_port_startup(struct tty_struct *tty, struct uart_state
>> *state,
>> +int init_hw);
>> +
>> +static void uart_port_shutdown(struct tty_port *port);
>> +
>> +void uart_register_rx_notification(struct uart_port *uport, int
>> (*function)(void *slave, unsigned int *c), struct ktermios *termios)
>> +{
>> +struct uart_state *state = uport->state;
>> +struct tty_port *tty_port = >port;
>> +
>> +if (!uport->slave)
>> +return; /* slave must be registered first */
>> +
>> +uport->rx_notification = function;
>> +
>> +if (tty_port->count == 0) {
>
> if (tty_port->count)
> return;
>
>> +if (function) {
>> +int retval = 0;
>
> Useless initialization.
Indeed.
>
>> +
>> +uart_change_pm(state, UART_PM_STATE_ON);
>> +retval = uport->ops->startup(uport);
>> +if (retval == 0 && termios) {
>
> Indentation is evil in this rather simple function :)
>
>> +int hw_stopped;
>> +/*
>> + * Initialise the hardware port settings.
>> + */
>> +uport->ops->set_termios(uport, termios, NULL);
>> +
>> +/*
>> + * Set modem status enables based on termios
>> cflag
>> + */
>> +spin_lock_irq(>lock);
>> +if (termios->c_cflag & CRTSCTS)
>> +uport->status |= UPSTAT_CTS_ENABLE;
>> +else
>> +uport->status &= ~UPSTAT_CTS_ENABLE;
>> +
>> +if (termios->c_cflag & CLOCAL)
>> +uport->status &= ~UPSTAT_DCD_ENABLE;
>> +else
>> +uport->status |= UPSTAT_DCD_ENABLE;
>> +
>> +/* reset sw-assisted CTS flow control based on
>> (possibly) new mode */
>
> checkpatch.pl will complain about long line :)
Ok.
>
>> +hw_stopped = uport->hw_stopped;
>> +uport->hw_stopped = uart_softcts_mode(uport) &&
>> +!(uport->ops->get_mctrl(uport) &
>> TIOCM_CTS);
>> +if (uport->hw_stopped) {
>> +if (!hw_stopped)
>> +uport->ops->stop_tx(uport);
>> +} else {
>> +if (hw_stopped)
>> +uport->ops->start_tx(uport);
>> +}
>> +spin_unlock_irq(>lock);
>> +}
>> +} else
>
> Usage of braces is against CodingStyle.
Ok.
>
>> +uart_port_shutdown(tty_port);
>> +}
>> +}
>> +
>> +EXPORT_SYMBOL_GPL(uart_register_slave);
>> +EXPORT_SYMBOL_GPL(uart_register_mctrl_notification);
>> +EXPORT_SYMBOL_GPL(uart_register_rx_notification);
>> +
>> /*
>> * This routine is used by the interrupt handler to schedule processing in
>> * the software interrupt portion of the driver.
>> @@ -220,6 +298,10 @@ uart_update_mctrl(struct uart_port *port, unsigned int
>> set, unsigned int clear)
>> port->mctrl = (old & ~clear) | set;
>> if (old != port->mctrl)
>> port->ops->set_mctrl(port, port->mctrl);
>> +
Re: [PATCH RFC v2 1/3] tty: serial core: provide method to search uart by phandle
Hi,
thanks for the comments.
Am 28.06.2015 um 23:34 schrieb Sergei Zviagintsev :
> Hi,
>
> Some comments below.
>
> On Sun, Jun 28, 2015 at 09:46:24PM +0200, Marek Belisko wrote:
>> From: "H. Nikolaus Schaller"
>>
>> 1. add registered uart_ports to a search list
>> 2. provide a function to search an uart_port by phandle. This copies the
>> mechanism how devm_usb_get_phy_by_phandle() works
>>
>> Signed-off-by: H. Nikolaus Schaller
>> Signed-off-by: Marek Belisko
>> ---
>> Documentation/serial/slaves.txt | 36 ++
>> drivers/tty/serial/serial_core.c | 103
>> +++
>> include/linux/serial_core.h | 10
>> 3 files changed, 149 insertions(+)
>> create mode 100644 Documentation/serial/slaves.txt
>>
>> diff --git a/Documentation/serial/slaves.txt
>> b/Documentation/serial/slaves.txt
>> new file mode 100644
>> index 000..6f8d44d
>> --- /dev/null
>> +++ b/Documentation/serial/slaves.txt
>> @@ -0,0 +1,36 @@
>> +UART slave device support
>> +
>> +A remote device connected to a RS232 interface is usually power controlled
>> by the DTR line.
>> +The DTR line is managed automatically by the UART driver for open() and
>> close() syscalls
>> +and on demand by tcsetattr().
>> +
>> +With embedded devices, the serial peripheral might be directly and always
>> connected to the UART
>> +and there might be no physical DTR line involved. Power control (on/off)
>> has to be done by some
>> +chip specific device driver (which we call "UART slave") through some
>> mechanisms (I2C, GPIOs etc.)
>> +not related to the serial interface. Some devices do not explicitly tell
>> their power state except
>> +by sending or not sending data to the UART. In such a case the device
>> driver must be able to monitor
>> +data activity. The role of the device driver is to encapsulate such power
>> control in a single place.
>> +
>> +This patch series allows to support such drivers by providing:
>> +* a mechanism that a slave driver can identify the UART instance it is
>> connected to
>> +* a mechanism that UART slave drivers can register to be notified
>> +* notfications for DTR (and other modem control) state changes
>> +* notifications that the UART has received some data from the UART
>> +
>> +A slave device simply adds a phandle reference to the UART it is connected
>> to, e.g.
>> +
>> +gps {
>> +compatible = "wi2wi,w2sg0004";
>> +uart = <>;
>> +};
>> +
>> +The slave driver calls devm_serial_get_uart_by_phandle() to identify the
>> uart driver.
>> +This API follows the concept of devm_usb_get_phy_by_phandle().
>> +
>> +A slave device driver registers itself with serial_register_slave() to
>> receive notifications.
>> +Notification handler callbacks can be registered by
>> serial_register_mctrl_notification() and
>> +serial_register_rx_notification(). If an UART has registered a NULL slave
>> or a NULL handler,
>> +no notifications are sent.
>> +
>> +RX notification handlers can define a ktermios during setup and the handler
>> function can modify
>> +or decide to throw away each character that is passed upwards.
>> diff --git a/drivers/tty/serial/serial_core.c
>> b/drivers/tty/serial/serial_core.c
>> index eec067d..ad61441 100644
>> --- a/drivers/tty/serial/serial_core.c
>> +++ b/drivers/tty/serial/serial_core.c
>> @@ -38,6 +38,33 @@
>> #include
>> #include
>>
>> +static LIST_HEAD(uart_list);
>> +static DEFINE_SPINLOCK(uart_lock);
>> +
>> +/* same concept as __of_usb_find_phy */
>> +static struct uart_port *__of_serial_find_uart(struct device_node *node)
>> +{
>> +struct uart_port *uart;
>> +
>> +if (!of_device_is_available(node))
>> +return ERR_PTR(-ENODEV);
>> +
>> +list_for_each_entry(uart, _list, head) {
>> +if (node != uart->dev->of_node)
>> +continue;
>> +
>> +return uart;
>
> We can easily save three lines here :)
Hm. We have copied from here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/phy/phy.c?id=refs/tags/v4.1#n65
So please let us know how you want to save 3 lines.
>
>> +}
>> +
>> +return ERR_PTR(-EPROBE_DEFER);
>> +}
>> +
>> +static void devm_serial_uart_release(struct device *dev, void *res)
>> +{
>> +struct uart_port *uart = *(struct uart_port **)res;
>> +/* FIXME: serial_put_uart(uart); */
>> +}
>
> Looks unfinished…
Yes indeed. That is why we submit it as a RFC. Maybe someone can give us a
comment
how memory management of uart nodes works.
>
>> +
>> /*
>> * This is used to lock changes in serial line configuration.
>> */
>> @@ -64,6 +91,78 @@ static int uart_dcd_enabled(struct uart_port *uport)
>> return !!(uport->status & UPSTAT_DCD_ENABLE);
>> }
>>
>> +/**
>> + * devm_serial_get_uart_by_phandle - find the uart by phandle
>> + * @dev - device that requests this uart
>> + * @phandle - name of the property holding the uart phandle value
>> + * @index - the index
Re: [PATCH RFC v2 1/3] tty: serial core: provide method to search uart by phandle
Hi,
thanks for the comments.
Am 28.06.2015 um 23:34 schrieb Sergei Zviagintsev ser...@s15v.net:
Hi,
Some comments below.
On Sun, Jun 28, 2015 at 09:46:24PM +0200, Marek Belisko wrote:
From: H. Nikolaus Schaller h...@goldelico.com
1. add registered uart_ports to a search list
2. provide a function to search an uart_port by phandle. This copies the
mechanism how devm_usb_get_phy_by_phandle() works
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
Signed-off-by: Marek Belisko ma...@goldelico.com
---
Documentation/serial/slaves.txt | 36 ++
drivers/tty/serial/serial_core.c | 103
+++
include/linux/serial_core.h | 10
3 files changed, 149 insertions(+)
create mode 100644 Documentation/serial/slaves.txt
diff --git a/Documentation/serial/slaves.txt
b/Documentation/serial/slaves.txt
new file mode 100644
index 000..6f8d44d
--- /dev/null
+++ b/Documentation/serial/slaves.txt
@@ -0,0 +1,36 @@
+UART slave device support
+
+A remote device connected to a RS232 interface is usually power controlled
by the DTR line.
+The DTR line is managed automatically by the UART driver for open() and
close() syscalls
+and on demand by tcsetattr().
+
+With embedded devices, the serial peripheral might be directly and always
connected to the UART
+and there might be no physical DTR line involved. Power control (on/off)
has to be done by some
+chip specific device driver (which we call UART slave) through some
mechanisms (I2C, GPIOs etc.)
+not related to the serial interface. Some devices do not explicitly tell
their power state except
+by sending or not sending data to the UART. In such a case the device
driver must be able to monitor
+data activity. The role of the device driver is to encapsulate such power
control in a single place.
+
+This patch series allows to support such drivers by providing:
+* a mechanism that a slave driver can identify the UART instance it is
connected to
+* a mechanism that UART slave drivers can register to be notified
+* notfications for DTR (and other modem control) state changes
+* notifications that the UART has received some data from the UART
+
+A slave device simply adds a phandle reference to the UART it is connected
to, e.g.
+
+gps {
+compatible = wi2wi,w2sg0004;
+uart = uart1;
+};
+
+The slave driver calls devm_serial_get_uart_by_phandle() to identify the
uart driver.
+This API follows the concept of devm_usb_get_phy_by_phandle().
+
+A slave device driver registers itself with serial_register_slave() to
receive notifications.
+Notification handler callbacks can be registered by
serial_register_mctrl_notification() and
+serial_register_rx_notification(). If an UART has registered a NULL slave
or a NULL handler,
+no notifications are sent.
+
+RX notification handlers can define a ktermios during setup and the handler
function can modify
+or decide to throw away each character that is passed upwards.
diff --git a/drivers/tty/serial/serial_core.c
b/drivers/tty/serial/serial_core.c
index eec067d..ad61441 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -38,6 +38,33 @@
#include asm/irq.h
#include asm/uaccess.h
+static LIST_HEAD(uart_list);
+static DEFINE_SPINLOCK(uart_lock);
+
+/* same concept as __of_usb_find_phy */
+static struct uart_port *__of_serial_find_uart(struct device_node *node)
+{
+struct uart_port *uart;
+
+if (!of_device_is_available(node))
+return ERR_PTR(-ENODEV);
+
+list_for_each_entry(uart, uart_list, head) {
+if (node != uart-dev-of_node)
+continue;
+
+return uart;
We can easily save three lines here :)
Hm. We have copied from here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/phy/phy.c?id=refs/tags/v4.1#n65
So please let us know how you want to save 3 lines.
+}
+
+return ERR_PTR(-EPROBE_DEFER);
+}
+
+static void devm_serial_uart_release(struct device *dev, void *res)
+{
+struct uart_port *uart = *(struct uart_port **)res;
+/* FIXME: serial_put_uart(uart); */
+}
Looks unfinished…
Yes indeed. That is why we submit it as a RFC. Maybe someone can give us a
comment
how memory management of uart nodes works.
+
/*
* This is used to lock changes in serial line configuration.
*/
@@ -64,6 +91,78 @@ static int uart_dcd_enabled(struct uart_port *uport)
return !!(uport-status UPSTAT_DCD_ENABLE);
}
+/**
+ * devm_serial_get_uart_by_phandle - find the uart by phandle
+ * @dev - device that requests this uart
+ * @phandle - name of the property holding the uart phandle value
+ * @index - the index of the uart
+ *
+ * Returns the uart_port associated with the given phandle value,
+ * after getting a refcount to it, -ENODEV if there is no such uart or
+ *
Re: [PATCH RFC v2 2/3] tty: serial_core: Add hooks for uart slave drivers
Hi,
thanks again.
Am 28.06.2015 um 23:51 schrieb Sergei Zviagintsev ser...@s15v.net:
Hi,
Some minor comments below.
On Sun, Jun 28, 2015 at 09:46:25PM +0200, Marek Belisko wrote:
From: H. Nikolaus Schaller h...@goldelico.com
1. allow drivers to get notified in mctrl changes
2. allow drivers to get notified on rx data (indicating to the driver that
the connected chip is active)
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
Signed-off-by: Marek Belisko ma...@goldelico.com
---
drivers/tty/serial/serial_core.c | 102
+--
include/linux/serial_core.h | 11 -
2 files changed, 107 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c
b/drivers/tty/serial/serial_core.c
index ad61441..c8910c4 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -163,6 +163,84 @@ err0:
}
EXPORT_SYMBOL_GPL(devm_serial_get_uart_by_phandle);
+void uart_register_slave(struct uart_port *uport, void *slave)
+{
+if (!slave) {
+uart_register_mctrl_notification(uport, NULL);
+uart_register_rx_notification(uport, NULL, NULL);
+}
+uport-slave = slave;
+}
+
+void uart_register_mctrl_notification(struct uart_port *uport, int
(*function)(void *slave, int state))
+{
+uport-mctrl_notification = function;
+}
+
+static int uart_port_startup(struct tty_struct *tty, struct uart_state
*state,
+int init_hw);
+
+static void uart_port_shutdown(struct tty_port *port);
+
+void uart_register_rx_notification(struct uart_port *uport, int
(*function)(void *slave, unsigned int *c), struct ktermios *termios)
+{
+struct uart_state *state = uport-state;
+struct tty_port *tty_port = state-port;
+
+if (!uport-slave)
+return; /* slave must be registered first */
+
+uport-rx_notification = function;
+
+if (tty_port-count == 0) {
if (tty_port-count)
return;
+if (function) {
+int retval = 0;
Useless initialization.
Indeed.
+
+uart_change_pm(state, UART_PM_STATE_ON);
+retval = uport-ops-startup(uport);
+if (retval == 0 termios) {
Indentation is evil in this rather simple function :)
+int hw_stopped;
+/*
+ * Initialise the hardware port settings.
+ */
+uport-ops-set_termios(uport, termios, NULL);
+
+/*
+ * Set modem status enables based on termios
cflag
+ */
+spin_lock_irq(uport-lock);
+if (termios-c_cflag CRTSCTS)
+uport-status |= UPSTAT_CTS_ENABLE;
+else
+uport-status = ~UPSTAT_CTS_ENABLE;
+
+if (termios-c_cflag CLOCAL)
+uport-status = ~UPSTAT_DCD_ENABLE;
+else
+uport-status |= UPSTAT_DCD_ENABLE;
+
+/* reset sw-assisted CTS flow control based on
(possibly) new mode */
checkpatch.pl will complain about long line :)
Ok.
+hw_stopped = uport-hw_stopped;
+uport-hw_stopped = uart_softcts_mode(uport)
+!(uport-ops-get_mctrl(uport)
TIOCM_CTS);
+if (uport-hw_stopped) {
+if (!hw_stopped)
+uport-ops-stop_tx(uport);
+} else {
+if (hw_stopped)
+uport-ops-start_tx(uport);
+}
+spin_unlock_irq(uport-lock);
+}
+} else
Usage of braces is against CodingStyle.
Ok.
+uart_port_shutdown(tty_port);
+}
+}
+
+EXPORT_SYMBOL_GPL(uart_register_slave);
+EXPORT_SYMBOL_GPL(uart_register_mctrl_notification);
+EXPORT_SYMBOL_GPL(uart_register_rx_notification);
+
/*
* This routine is used by the interrupt handler to schedule processing in
* the software interrupt portion of the driver.
@@ -220,6 +298,10 @@ uart_update_mctrl(struct uart_port *port, unsigned int
set, unsigned int clear)
port-mctrl = (old ~clear) | set;
if (old != port-mctrl)
port-ops-set_mctrl(port, port-mctrl);
+
+if (port-mctrl_notification)
+(*port-mctrl_notification)(port-slave, port-mctrl);
+
spin_unlock_irqrestore(port-lock, flags);
}
@@ -259,7 +341,8 @@ static int
Re: [Gta04-owner] [PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.
Hi Neil,
Am 01.06.2015 um 23:37 schrieb NeilBrown :
> On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I
> wrote:
>
>> Hi,
>>
>> On Thursday 16 April 2015 01:33 PM, NeilBrown wrote:
>>> From: NeilBrown
>>>
>>> The twl4030 phy can measure, with low precision, the
>>> resistance-to-ground of the ID pin.
>>>
>>> Add a function to read the value, and export the result
>>> via sysfs.
>>
>> Little sceptical about adding new sysfs entries. Do you have a good reason
>> to
>> add this?
>
> The hardware can report the value, so why not present it to user-space?
I just had another idea how to present the value to user space.
The TWL6030 has connected the USB ID pin to one of the GPADC channels:
http://lxr.free-electrons.com/source/drivers/iio/adc/twl6030-gpadc.c#L235
And therefore automatically presents the ID pin voltage through iio.
Would it be possible and useful to provide an iio interface for the
resistance-to-ground
of the tw4030 ID pin as well?
This would resemble a 6 or 7 level ADC with non-linear scale, but better than
nothing.
And to avoid the “floating” issue, it could also present some voltage value
(assuming
a defined current).
So that “floating” is reported as some maximum voltage (e.g. 3.3V) and “ground”
as 0V.
What do you think?
BR,
Nikolaus
>
> I originally used this with a udev rule which would configure the maximum
> current based on the resistance measure - to work with the particular charger
> hardware I have.
>
> More recent patches try to do all of the max-current configuration in the
> kernel, so I could live without exporting the value via sysfs if that is a
> show-stopper.
>
> I can't see where the scepticism comes from though. It is a well defined
> and cleary documented feature of the hardware. Why not expose it?
>
> Thanks,
> NeilBrown
>
>
>>
>> Thanks
>> Kishon
>>>
>>> If the read fails, which it does sometimes, try again in 50msec.
>>>
>>> Acked-by: Pavel Machek
>>> Signed-off-by: NeilBrown
>>> ---
>>> .../ABI/testing/sysfs-platform-twl4030-usb | 22 +++
>>> drivers/phy/phy-twl4030-usb.c | 63
>>>
>>> 2 files changed, 85 insertions(+)
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
>>> b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
>>> index 512c51be64ae..425d23676f8a 100644
>>> --- a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
>>> +++ b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
>>> @@ -6,3 +6,25 @@ Description:
>>> Possible values: "on", "off".
>>>
>>> Changes are notified via select/poll.
>>> +
>>> +What: /sys/bus/platform/devices/*twl4030-usb/id
>>> +Description:
>>> + Read-only report on measurement of USB-OTG ID pin.
>>> +
>>> + The ID pin may be floating, grounded, or pulled to
>>> + ground by a resistor.
>>> +
>>> + A very course grained reading of the resistance is
>>> + available. The numbers given in kilo-ohms are roughly
>>> + the center-point of the detected range.
>>> +
>>> + Possible values are:
>>> + ground
>>> + 102k
>>> + 200k
>>> + 440k
>>> + floating
>>> + unknown
>>> +
>>> + "unknown" indicates a problem with trying to detect
>>> + the resistance.
>>> diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
>>> index 3a707dd14238..1d6f3e70193e 100644
>>> --- a/drivers/phy/phy-twl4030-usb.c
>>> +++ b/drivers/phy/phy-twl4030-usb.c
>>> @@ -379,6 +379,56 @@ static void twl4030_i2c_access(struct twl4030_usb
>>> *twl, int on)
>>> }
>>> }
>>>
>>> +enum twl4030_id_status {
>>> + TWL4030_GROUND,
>>> + TWL4030_102K,
>>> + TWL4030_200K,
>>> + TWL4030_440K,
>>> + TWL4030_FLOATING,
>>> + TWL4030_ID_UNKNOWN,
>>> +};
>>> +static char *twl4030_id_names[] = {
>>> + "ground",
>>> + "102k",
>>> + "200k",
>>> + "440k",
>>> + "floating",
>>> + "unknown"
>>> +};
>>> +
>>> +enum twl4030_id_status twl4030_get_id(struct twl4030_usb *twl)
>>> +{
>>> + int ret;
>>> +
>>> + pm_runtime_get_sync(twl->dev);
>>> + if (twl->usb_mode == T2_USB_MODE_ULPI)
>>> + twl4030_i2c_access(twl, 1);
>>> + ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
>>> + if (ret < 0 || !(ret & ULPI_OTG_ID_PULLUP)) {
>>> + /* Need pull-up to read ID */
>>> + twl4030_usb_set_bits(twl, ULPI_OTG_CTRL,
>>> +ULPI_OTG_ID_PULLUP);
>>> + mdelay(50);
>>> + }
>>> + ret = twl4030_usb_read(twl, ID_STATUS);
>>> + if (ret < 0 || (ret & 0x1f) == 0) {
>>> + mdelay(50);
>>> + ret = twl4030_usb_read(twl, ID_STATUS);
>>> + }
>>> +
>>> + if (twl->usb_mode == T2_USB_MODE_ULPI)
>>> + twl4030_i2c_access(twl, 0);
>>> + pm_runtime_put_autosuspend(twl->dev);
>>> +
>>> + if (ret < 0)
>>> + return TWL4030_ID_UNKNOWN;
>>> + ret = ffs(ret) - 1;
>>> + if (ret < TWL4030_GROUND || ret > TWL4030_FLOATING)
>>> +
Re: [Gta04-owner] [PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.
Hi Neil,
Am 01.06.2015 um 23:37 schrieb NeilBrown ne...@suse.de:
On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi,
On Thursday 16 April 2015 01:33 PM, NeilBrown wrote:
From: NeilBrown ne...@suse.de
The twl4030 phy can measure, with low precision, the
resistance-to-ground of the ID pin.
Add a function to read the value, and export the result
via sysfs.
Little sceptical about adding new sysfs entries. Do you have a good reason
to
add this?
The hardware can report the value, so why not present it to user-space?
I just had another idea how to present the value to user space.
The TWL6030 has connected the USB ID pin to one of the GPADC channels:
http://lxr.free-electrons.com/source/drivers/iio/adc/twl6030-gpadc.c#L235
And therefore automatically presents the ID pin voltage through iio.
Would it be possible and useful to provide an iio interface for the
resistance-to-ground
of the tw4030 ID pin as well?
This would resemble a 6 or 7 level ADC with non-linear scale, but better than
nothing.
And to avoid the “floating” issue, it could also present some voltage value
(assuming
a defined current).
So that “floating” is reported as some maximum voltage (e.g. 3.3V) and “ground”
as 0V.
What do you think?
BR,
Nikolaus
I originally used this with a udev rule which would configure the maximum
current based on the resistance measure - to work with the particular charger
hardware I have.
More recent patches try to do all of the max-current configuration in the
kernel, so I could live without exporting the value via sysfs if that is a
show-stopper.
I can't see where the scepticism comes from though. It is a well defined
and cleary documented feature of the hardware. Why not expose it?
Thanks,
NeilBrown
Thanks
Kishon
If the read fails, which it does sometimes, try again in 50msec.
Acked-by: Pavel Machek pa...@ucw.cz
Signed-off-by: NeilBrown ne...@suse.de
---
.../ABI/testing/sysfs-platform-twl4030-usb | 22 +++
drivers/phy/phy-twl4030-usb.c | 63
2 files changed, 85 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
index 512c51be64ae..425d23676f8a 100644
--- a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
+++ b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
@@ -6,3 +6,25 @@ Description:
Possible values: on, off.
Changes are notified via select/poll.
+
+What: /sys/bus/platform/devices/*twl4030-usb/id
+Description:
+ Read-only report on measurement of USB-OTG ID pin.
+
+ The ID pin may be floating, grounded, or pulled to
+ ground by a resistor.
+
+ A very course grained reading of the resistance is
+ available. The numbers given in kilo-ohms are roughly
+ the center-point of the detected range.
+
+ Possible values are:
+ ground
+ 102k
+ 200k
+ 440k
+ floating
+ unknown
+
+ unknown indicates a problem with trying to detect
+ the resistance.
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 3a707dd14238..1d6f3e70193e 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -379,6 +379,56 @@ static void twl4030_i2c_access(struct twl4030_usb
*twl, int on)
}
}
+enum twl4030_id_status {
+ TWL4030_GROUND,
+ TWL4030_102K,
+ TWL4030_200K,
+ TWL4030_440K,
+ TWL4030_FLOATING,
+ TWL4030_ID_UNKNOWN,
+};
+static char *twl4030_id_names[] = {
+ ground,
+ 102k,
+ 200k,
+ 440k,
+ floating,
+ unknown
+};
+
+enum twl4030_id_status twl4030_get_id(struct twl4030_usb *twl)
+{
+ int ret;
+
+ pm_runtime_get_sync(twl-dev);
+ if (twl-usb_mode == T2_USB_MODE_ULPI)
+ twl4030_i2c_access(twl, 1);
+ ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
+ if (ret 0 || !(ret ULPI_OTG_ID_PULLUP)) {
+ /* Need pull-up to read ID */
+ twl4030_usb_set_bits(twl, ULPI_OTG_CTRL,
+ULPI_OTG_ID_PULLUP);
+ mdelay(50);
+ }
+ ret = twl4030_usb_read(twl, ID_STATUS);
+ if (ret 0 || (ret 0x1f) == 0) {
+ mdelay(50);
+ ret = twl4030_usb_read(twl, ID_STATUS);
+ }
+
+ if (twl-usb_mode == T2_USB_MODE_ULPI)
+ twl4030_i2c_access(twl, 0);
+ pm_runtime_put_autosuspend(twl-dev);
+
+ if (ret 0)
+ return TWL4030_ID_UNKNOWN;
+ ret = ffs(ret) - 1;
+ if (ret TWL4030_GROUND || ret TWL4030_FLOATING)
+ return TWL4030_ID_UNKNOWN;
+
+ return ret;
+}
+
static void __twl4030_phy_power(struct twl4030_usb *twl, int on)
{
u8 pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
@@ -532,6 +582,16 @@ static ssize_t twl4030_usb_vbus_show(struct device
*dev,
}
static DEVICE_ATTR(vbus, 0444, twl4030_usb_vbus_show,
Re: [PATCH 1/2] iio: adc: twl4030_madc: Fix calculation of the temperature sense current
Am 07.06.2015 um 18:25 schrieb Jonathan Cameron : > On 28/05/15 20:50, Marek Belisko wrote: >> From: "H. Nikolaus Schaller" >> >> The bit mask to read the setting of the constant current source >> for measuring the NTC voltage was the wrong one. Since default >> value is initialized to the lowest level (000 = 10uA) the difference >> was probably never noticed in practice. > I'm going to take that literally and apply it via the slow route on > the basis that a bug no one noticed doesn’t need fixing fast! Yes, that is fine. >> >> Signed-off-by: H. Nikolaus Schaller >> Signed-off-by: Marek Belisko > Applied to the togreg branch of iio.git - initially pushed out as > testing for the autobuilders to play with it. > > Thanks, > > Jonathan Thanks, Nikolaus >> --- >> drivers/iio/adc/twl4030-madc.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/iio/adc/twl4030-madc.c b/drivers/iio/adc/twl4030-madc.c >> index 94c5f05..6d2d429 100644 >> --- a/drivers/iio/adc/twl4030-madc.c >> +++ b/drivers/iio/adc/twl4030-madc.c >> @@ -235,7 +235,7 @@ static int twl4030battery_temperature(int raw_volt) >> if (ret < 0) >> return ret; >> >> -curr = ((val & TWL4030_BCI_ITHEN) + 1) * 10; >> +curr = ((val & TWL4030_BCI_ITHSENS) + 1) * 10; >> /* Getting and calculating the thermistor resistance in ohms */ >> res = volt * 1000 / curr; >> /* calculating temperature */ >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] iio: adc: twl4030_madc: Fix calculation of the temperature sense current
Am 07.06.2015 um 18:25 schrieb Jonathan Cameron ji...@kernel.org: On 28/05/15 20:50, Marek Belisko wrote: From: H. Nikolaus Schaller h...@goldelico.com The bit mask to read the setting of the constant current source for measuring the NTC voltage was the wrong one. Since default value is initialized to the lowest level (000 = 10uA) the difference was probably never noticed in practice. I'm going to take that literally and apply it via the slow route on the basis that a bug no one noticed doesn’t need fixing fast! Yes, that is fine. Signed-off-by: H. Nikolaus Schaller h...@goldelico.com Signed-off-by: Marek Belisko ma...@goldelico.com Applied to the togreg branch of iio.git - initially pushed out as testing for the autobuilders to play with it. Thanks, Jonathan Thanks, Nikolaus --- drivers/iio/adc/twl4030-madc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/twl4030-madc.c b/drivers/iio/adc/twl4030-madc.c index 94c5f05..6d2d429 100644 --- a/drivers/iio/adc/twl4030-madc.c +++ b/drivers/iio/adc/twl4030-madc.c @@ -235,7 +235,7 @@ static int twl4030battery_temperature(int raw_volt) if (ret 0) return ret; -curr = ((val TWL4030_BCI_ITHEN) + 1) * 10; +curr = ((val TWL4030_BCI_ITHSENS) + 1) * 10; /* Getting and calculating the thermistor resistance in ohms */ res = volt * 1000 / curr; /* calculating temperature */ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 0/3] UART slave device support
Hi all,
this patch series is our proposal to add hooks so that the driver for a device
connected to an UART can
monitor modem control lines and data activity of the connected chip.
It contains an example for such a device driver which needs such sophisticated
power control: wi2wi,w2sg0004
A remote device connected to a RS232 interface is usually power controlled by
the DTR line.
The DTR line is managed automatically by the UART driver for open() and close()
syscalls
and on demand by tcsetattr().
With embedded devices, the serial peripheral might be directly and always
connected to the UART
and there might be no physical DTR line involved. Power control (on/off) has to
be done by some
chip specific device driver (which we call "UART slave") through some
mechanisms (I2C, GPIOs etc.)
not related to the serial interface. Some devices do not tell their power state
except by sending
or not sending data to the UART. In such a case the device driver must be able
to monitor data
activity. The role of the device driver is to encapsulate such power control in
a single place.
This patch series allows to support such UART slave drivers by providing:
* a mechanism that a slave driver can identify the UART instance it is
connected to
* a mechanism that UART slave drivers can register to be notified
* notfications for DTR (and other modem control) state changes
* notifications that the device has sent some data to the UART
A slave device tree entry simply adds a phandle reference to the UART it is
connected to, e.g.
gps {
compatible = "wi2wi,w2sg0004";
uart = <>;
};
The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart
driver.
devm_serial_get_uart_by_phandle() follows the concept of
devm_usb_get_phy_by_phandle().
A slave device driver registers itself with serial_register_slave() to receive
notifications.
Notification handlers can be registered by serial_register_mctrl_notification()
and
serial_register_rx_notification(). If an UART has a NULL slave or a NULL
handler registered,
no notifications are sent.
RX notification handlers can define a ktermios setup and modify or decide to
throw away the
character that is passed upwards.
This all is a follow-up to the w2sg0004 driver submitted in 2014 that did want
to add an optional
GPIO to DTR in omap-serial.c and required the w2sg0004 driver to present itself
as a "virtual
GPIO". The idea of a "virtual GPIO" is not compatible with the concept that DT
must
describe hardware (and not virtual hardware). So in this new solution DT only
describes that
the w2sg0004 is connected to some UART and how the power state signalling works
is left
to the driver implementations.
The rx data notification also removes the concept of having two different
pinmux states
and make the w2sg0004 driver intercept rx activities by switching the rx line
to a GPIO
interrupt. This was very OMAP3 specific. The new solution is generic and might
even be
extensible that the chip driver could filter or consume the rx data before it
is passed
to the tty layer.
This patch works on linux-next as intended except one major weakness: we have
to call
uart_change_speed() each time we open the tty. This is the opposite of what we
would like
to have: that the slave initializes the uart speed through some termios and the
tty level just uses
this setting. We have not yet completely understood how to make this work and
are happy
about help in this area.
And of course we would like to see general comments about the whole
implementation
approach.
Signed-off-by: H. Nikolaus Schaller
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 0/3] UART slave device support
Hi all,
this patch series is our proposal to add hooks so that the driver for a device
connected to an UART can
monitor modem control lines and data activity of the connected chip.
It contains an example for such a device driver which needs such sophisticated
power control: wi2wi,w2sg0004
A remote device connected to a RS232 interface is usually power controlled by
the DTR line.
The DTR line is managed automatically by the UART driver for open() and close()
syscalls
and on demand by tcsetattr().
With embedded devices, the serial peripheral might be directly and always
connected to the UART
and there might be no physical DTR line involved. Power control (on/off) has to
be done by some
chip specific device driver (which we call UART slave) through some
mechanisms (I2C, GPIOs etc.)
not related to the serial interface. Some devices do not tell their power state
except by sending
or not sending data to the UART. In such a case the device driver must be able
to monitor data
activity. The role of the device driver is to encapsulate such power control in
a single place.
This patch series allows to support such UART slave drivers by providing:
* a mechanism that a slave driver can identify the UART instance it is
connected to
* a mechanism that UART slave drivers can register to be notified
* notfications for DTR (and other modem control) state changes
* notifications that the device has sent some data to the UART
A slave device tree entry simply adds a phandle reference to the UART it is
connected to, e.g.
gps {
compatible = wi2wi,w2sg0004;
uart = uart1;
};
The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart
driver.
devm_serial_get_uart_by_phandle() follows the concept of
devm_usb_get_phy_by_phandle().
A slave device driver registers itself with serial_register_slave() to receive
notifications.
Notification handlers can be registered by serial_register_mctrl_notification()
and
serial_register_rx_notification(). If an UART has a NULL slave or a NULL
handler registered,
no notifications are sent.
RX notification handlers can define a ktermios setup and modify or decide to
throw away the
character that is passed upwards.
This all is a follow-up to the w2sg0004 driver submitted in 2014 that did want
to add an optional
GPIO to DTR in omap-serial.c and required the w2sg0004 driver to present itself
as a virtual
GPIO. The idea of a virtual GPIO is not compatible with the concept that DT
must
describe hardware (and not virtual hardware). So in this new solution DT only
describes that
the w2sg0004 is connected to some UART and how the power state signalling works
is left
to the driver implementations.
The rx data notification also removes the concept of having two different
pinmux states
and make the w2sg0004 driver intercept rx activities by switching the rx line
to a GPIO
interrupt. This was very OMAP3 specific. The new solution is generic and might
even be
extensible that the chip driver could filter or consume the rx data before it
is passed
to the tty layer.
This patch works on linux-next as intended except one major weakness: we have
to call
uart_change_speed() each time we open the tty. This is the opposite of what we
would like
to have: that the slave initializes the uart speed through some termios and the
tty level just uses
this setting. We have not yet completely understood how to make this work and
are happy
about help in this area.
And of course we would like to see general comments about the whole
implementation
approach.
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.
Hi, Am 02.06.2015 um 22:11 schrieb Pavel Machek : > On Tue 2015-06-02 16:06:47, Dr. H. Nikolaus Schaller wrote: >> Hi, >> >> Am 02.06.2015 um 15:49 schrieb Kishon Vijay Abraham I : >> >>> Hi, >>> >>> On Tuesday 02 June 2015 03:07 AM, NeilBrown wrote: >>>> On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Thursday 16 April 2015 01:33 PM, NeilBrown wrote: >>>>>> From: NeilBrown >>>>>> >>>>>> The twl4030 phy can measure, with low precision, the >>>>>> resistance-to-ground of the ID pin. >>>>>> >>>>>> Add a function to read the value, and export the result >>>>>> via sysfs. >>>>> >>>>> Little sceptical about adding new sysfs entries. Do you have a good >>>>> reason to >>>>> add this? >>>> >>>> The hardware can report the value, so why not present it to user-space? >>>> >>>> I originally used this with a udev rule which would configure the maximum >>>> current based on the resistance measure - to work with the particular >>>> charger >>>> hardware I have. >>>> >>>> More recent patches try to do all of the max-current configuration in the >>>> kernel, so I could live without exporting the value via sysfs if that is a >>>> show-stopper. >>>> >>>> I can't see where the scepticism comes from though. It is a well defined >>>> and cleary documented feature of the hardware. Why not expose it? > > Is it well defined enough that it will work on other chargers, too? It reports the resistance of the charger’s ID pin. So that works for all chargers connected to a twl4030. As long as the ID pin goes to a 5 pin USB socket. Other charger drivers do not need to expose a similar attribute since each twl4030 has its unique path within the /sys tree. > >>> ABI can never be removed or modified later. So should be really careful >>> before adding it. >> >> Is /sys considered ABI? > > Yes. You are right: https://lwn.net/Articles/172986/ But I am as well with my doubts: https://lwn.net/Articles/173093/ > >> User space developers are always reminded not to rely on /sys nodes. > > No. Then please explain why I have the impression that it is quite unstable. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.
Hi,
Am 02.06.2015 um 15:49 schrieb Kishon Vijay Abraham I :
> Hi,
>
> On Tuesday 02 June 2015 03:07 AM, NeilBrown wrote:
>> On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I
>> wrote:
>>
>>> Hi,
>>>
>>> On Thursday 16 April 2015 01:33 PM, NeilBrown wrote:
From: NeilBrown
The twl4030 phy can measure, with low precision, the
resistance-to-ground of the ID pin.
Add a function to read the value, and export the result
via sysfs.
>>>
>>> Little sceptical about adding new sysfs entries. Do you have a good reason
>>> to
>>> add this?
>>
>> The hardware can report the value, so why not present it to user-space?
>>
>> I originally used this with a udev rule which would configure the maximum
>> current based on the resistance measure - to work with the particular charger
>> hardware I have.
>>
>> More recent patches try to do all of the max-current configuration in the
>> kernel, so I could live without exporting the value via sysfs if that is a
>> show-stopper.
>>
>> I can't see where the scepticism comes from though. It is a well defined
>> and cleary documented feature of the hardware. Why not expose it?
>
> ABI can never be removed or modified later. So should be really careful
> before adding it.
Is /sys considered ABI? It is permanently changing. At least in what I see.
User space developers are always reminded not to rely on /sys nodes.
Or if they do they have to follow kernel changes at their own risk.
And if something is useful (and has a use case as Neil mentioned), why shouldn’t
it be provided.
There are use cases where user space needs to know the value. Udev rule being
an example. E.g. to make LEDs show the state.
Or see it as a debugging tool. Just cat /sys/…path…/id to check if your 3 types
of charger are recognised properly.
Or write a tool that displays the charger type.
So isn’t that a little too narrow view applied here?
Just my opinion.
BR,
Nikolaus
>
> Thanks
> Kishon
>
>>
>> Thanks,
>> NeilBrown
>>
>>
>>>
>>> Thanks
>>> Kishon
If the read fails, which it does sometimes, try again in 50msec.
Acked-by: Pavel Machek
Signed-off-by: NeilBrown
---
.../ABI/testing/sysfs-platform-twl4030-usb | 22 +++
drivers/phy/phy-twl4030-usb.c | 63
2 files changed, 85 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
index 512c51be64ae..425d23676f8a 100644
--- a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
+++ b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
@@ -6,3 +6,25 @@ Description:
Possible values: "on", "off".
Changes are notified via select/poll.
+
+What: /sys/bus/platform/devices/*twl4030-usb/id
+Description:
+ Read-only report on measurement of USB-OTG ID pin.
+
+ The ID pin may be floating, grounded, or pulled to
+ ground by a resistor.
+
+ A very course grained reading of the resistance is
+ available. The numbers given in kilo-ohms are roughly
+ the center-point of the detected range.
+
+ Possible values are:
+ ground
+ 102k
+ 200k
+ 440k
+ floating
+ unknown
+
+ "unknown" indicates a problem with trying to detect
+ the resistance.
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 3a707dd14238..1d6f3e70193e 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -379,6 +379,56 @@ static void twl4030_i2c_access(struct twl4030_usb
*twl, int on)
}
}
+enum twl4030_id_status {
+ TWL4030_GROUND,
+ TWL4030_102K,
+ TWL4030_200K,
+ TWL4030_440K,
+ TWL4030_FLOATING,
+ TWL4030_ID_UNKNOWN,
+};
+static char *twl4030_id_names[] = {
+ "ground",
+ "102k",
+ "200k",
+ "440k",
+ "floating",
+ "unknown"
+};
+
+enum twl4030_id_status twl4030_get_id(struct twl4030_usb *twl)
+{
+ int ret;
+
+ pm_runtime_get_sync(twl->dev);
+ if (twl->usb_mode == T2_USB_MODE_ULPI)
+ twl4030_i2c_access(twl, 1);
+ ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
+ if (ret < 0 || !(ret & ULPI_OTG_ID_PULLUP)) {
+ /* Need pull-up to read ID */
+ twl4030_usb_set_bits(twl, ULPI_OTG_CTRL,
+ ULPI_OTG_ID_PULLUP);
+ mdelay(50);
+ }
+ ret = twl4030_usb_read(twl, ID_STATUS);
+ if (ret < 0 || (ret & 0x1f) == 0) {
+ mdelay(50);
+ ret = twl4030_usb_read(twl, ID_STATUS);
+ }
+
+ if (twl->usb_mode == T2_USB_MODE_ULPI)
+
Re: [Gta04-owner] [PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.
Hi, Am 02.06.2015 um 22:11 schrieb Pavel Machek pa...@ucw.cz: On Tue 2015-06-02 16:06:47, Dr. H. Nikolaus Schaller wrote: Hi, Am 02.06.2015 um 15:49 schrieb Kishon Vijay Abraham I kis...@ti.com: Hi, On Tuesday 02 June 2015 03:07 AM, NeilBrown wrote: On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Thursday 16 April 2015 01:33 PM, NeilBrown wrote: From: NeilBrown ne...@suse.de The twl4030 phy can measure, with low precision, the resistance-to-ground of the ID pin. Add a function to read the value, and export the result via sysfs. Little sceptical about adding new sysfs entries. Do you have a good reason to add this? The hardware can report the value, so why not present it to user-space? I originally used this with a udev rule which would configure the maximum current based on the resistance measure - to work with the particular charger hardware I have. More recent patches try to do all of the max-current configuration in the kernel, so I could live without exporting the value via sysfs if that is a show-stopper. I can't see where the scepticism comes from though. It is a well defined and cleary documented feature of the hardware. Why not expose it? Is it well defined enough that it will work on other chargers, too? It reports the resistance of the charger’s ID pin. So that works for all chargers connected to a twl4030. As long as the ID pin goes to a 5 pin USB socket. Other charger drivers do not need to expose a similar attribute since each twl4030 has its unique path within the /sys tree. ABI can never be removed or modified later. So should be really careful before adding it. Is /sys considered ABI? Yes. You are right: https://lwn.net/Articles/172986/ But I am as well with my doubts: https://lwn.net/Articles/173093/ User space developers are always reminded not to rely on /sys nodes. No. Then please explain why I have the impression that it is quite unstable. BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.
Hi,
Am 02.06.2015 um 15:49 schrieb Kishon Vijay Abraham I kis...@ti.com:
Hi,
On Tuesday 02 June 2015 03:07 AM, NeilBrown wrote:
On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi,
On Thursday 16 April 2015 01:33 PM, NeilBrown wrote:
From: NeilBrown ne...@suse.de
The twl4030 phy can measure, with low precision, the
resistance-to-ground of the ID pin.
Add a function to read the value, and export the result
via sysfs.
Little sceptical about adding new sysfs entries. Do you have a good reason
to
add this?
The hardware can report the value, so why not present it to user-space?
I originally used this with a udev rule which would configure the maximum
current based on the resistance measure - to work with the particular charger
hardware I have.
More recent patches try to do all of the max-current configuration in the
kernel, so I could live without exporting the value via sysfs if that is a
show-stopper.
I can't see where the scepticism comes from though. It is a well defined
and cleary documented feature of the hardware. Why not expose it?
ABI can never be removed or modified later. So should be really careful
before adding it.
Is /sys considered ABI? It is permanently changing. At least in what I see.
User space developers are always reminded not to rely on /sys nodes.
Or if they do they have to follow kernel changes at their own risk.
And if something is useful (and has a use case as Neil mentioned), why shouldn’t
it be provided.
There are use cases where user space needs to know the value. Udev rule being
an example. E.g. to make LEDs show the state.
Or see it as a debugging tool. Just cat /sys/…path…/id to check if your 3 types
of charger are recognised properly.
Or write a tool that displays the charger type.
So isn’t that a little too narrow view applied here?
Just my opinion.
BR,
Nikolaus
Thanks
Kishon
Thanks,
NeilBrown
Thanks
Kishon
If the read fails, which it does sometimes, try again in 50msec.
Acked-by: Pavel Machek pa...@ucw.cz
Signed-off-by: NeilBrown ne...@suse.de
---
.../ABI/testing/sysfs-platform-twl4030-usb | 22 +++
drivers/phy/phy-twl4030-usb.c | 63
2 files changed, 85 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
index 512c51be64ae..425d23676f8a 100644
--- a/Documentation/ABI/testing/sysfs-platform-twl4030-usb
+++ b/Documentation/ABI/testing/sysfs-platform-twl4030-usb
@@ -6,3 +6,25 @@ Description:
Possible values: on, off.
Changes are notified via select/poll.
+
+What: /sys/bus/platform/devices/*twl4030-usb/id
+Description:
+ Read-only report on measurement of USB-OTG ID pin.
+
+ The ID pin may be floating, grounded, or pulled to
+ ground by a resistor.
+
+ A very course grained reading of the resistance is
+ available. The numbers given in kilo-ohms are roughly
+ the center-point of the detected range.
+
+ Possible values are:
+ ground
+ 102k
+ 200k
+ 440k
+ floating
+ unknown
+
+ unknown indicates a problem with trying to detect
+ the resistance.
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 3a707dd14238..1d6f3e70193e 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -379,6 +379,56 @@ static void twl4030_i2c_access(struct twl4030_usb
*twl, int on)
}
}
+enum twl4030_id_status {
+ TWL4030_GROUND,
+ TWL4030_102K,
+ TWL4030_200K,
+ TWL4030_440K,
+ TWL4030_FLOATING,
+ TWL4030_ID_UNKNOWN,
+};
+static char *twl4030_id_names[] = {
+ ground,
+ 102k,
+ 200k,
+ 440k,
+ floating,
+ unknown
+};
+
+enum twl4030_id_status twl4030_get_id(struct twl4030_usb *twl)
+{
+ int ret;
+
+ pm_runtime_get_sync(twl-dev);
+ if (twl-usb_mode == T2_USB_MODE_ULPI)
+ twl4030_i2c_access(twl, 1);
+ ret = twl4030_usb_read(twl, ULPI_OTG_CTRL);
+ if (ret 0 || !(ret ULPI_OTG_ID_PULLUP)) {
+ /* Need pull-up to read ID */
+ twl4030_usb_set_bits(twl, ULPI_OTG_CTRL,
+ ULPI_OTG_ID_PULLUP);
+ mdelay(50);
+ }
+ ret = twl4030_usb_read(twl, ID_STATUS);
+ if (ret 0 || (ret 0x1f) == 0) {
+ mdelay(50);
+ ret = twl4030_usb_read(twl, ID_STATUS);
+ }
+
+ if (twl-usb_mode == T2_USB_MODE_ULPI)
+ twl4030_i2c_access(twl, 0);
+ pm_runtime_put_autosuspend(twl-dev);
+
+ if (ret 0)
+ return TWL4030_ID_UNKNOWN;
+ ret = ffs(ret) - 1;
+ if (ret TWL4030_GROUND || ret TWL4030_FLOATING)
+ return TWL4030_ID_UNKNOWN;
+
+ return ret;
+}
+
static void __twl4030_phy_power(struct twl4030_usb *twl, int on)
{
u8 pwr = twl4030_usb_read(twl, PHY_PWR_CTRL);
@@ -532,6 +582,16 @@ static ssize_t
Re: [RFC/RFT v2 0/2] power_supply: Fix NULL pointer dereference from uevent
Am 21.05.2015 um 00:20 schrieb Sebastian Reichel : > Hi, > > On Tue, May 19, 2015 at 10:28:39AM +0200, Dr. H. Nikolaus Schaller wrote: >> Am 19.05.2015 um 09:13 schrieb Krzysztof Kozlowski : >>> Changes since v1: >>> = >>> 1. Patch 2: fix invalid member used for container_of(). >>> 2. Patch 2: Replace WARN with pr_warn() in __power_supply_register() >>> if parent is missing. >>> >>> >>> Description: >>> >>> This is an idea to fix issue in bq27x00 driver (and probably in others) >>> reported by H. Nikolaus Schaller [0]. >>> >>> The fixes are marked RFC/RFT because: >>> 1. I do not have bq27x00-like device. I confirmed this and tested on >>> modified drivers (max77693, ACPI AC). These drivers are not >>> impacted by the issue but one can easily adjust them to reproduce >>> the problem. >>> 2. The first uevent coming from power_supply_register() is now >>> different because it won't contain device properties. I am >>> not sure how this impacts userspace. >>> >>> Comments are welcomed. >> >> appears to work! bq27000 is coming up now without hickups. >> >> What I can’t test is if the uevent is reasonable because we do not >> have a specific rule triggered by it in our system. >> >> So from my side we are now happy with the solution. > > So you would be ok with the following added to the patches? > > Tested-By: Dr. H. Nikolaus Schaller Yes, please add. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/RFT v2 0/2] power_supply: Fix NULL pointer dereference from uevent
Am 21.05.2015 um 00:20 schrieb Sebastian Reichel s...@kernel.org: Hi, On Tue, May 19, 2015 at 10:28:39AM +0200, Dr. H. Nikolaus Schaller wrote: Am 19.05.2015 um 09:13 schrieb Krzysztof Kozlowski k.kozlow...@samsung.com: Changes since v1: = 1. Patch 2: fix invalid member used for container_of(). 2. Patch 2: Replace WARN with pr_warn() in __power_supply_register() if parent is missing. Description: This is an idea to fix issue in bq27x00 driver (and probably in others) reported by H. Nikolaus Schaller [0]. The fixes are marked RFC/RFT because: 1. I do not have bq27x00-like device. I confirmed this and tested on modified drivers (max77693, ACPI AC). These drivers are not impacted by the issue but one can easily adjust them to reproduce the problem. 2. The first uevent coming from power_supply_register() is now different because it won't contain device properties. I am not sure how this impacts userspace. Comments are welcomed. appears to work! bq27000 is coming up now without hickups. What I can’t test is if the uevent is reasonable because we do not have a specific rule triggered by it in our system. So from my side we are now happy with the solution. So you would be ok with the following added to the patches? Tested-By: Dr. H. Nikolaus Schaller h...@goldelico.com Yes, please add. BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/RFT v2 0/2] power_supply: Fix NULL pointer dereference from uevent
Hi, Am 19.05.2015 um 09:13 schrieb Krzysztof Kozlowski : > Hi, > > > Changes since v1: > = > 1. Patch 2: fix invalid member used for container_of(). > 2. Patch 2: Replace WARN with pr_warn() in __power_supply_register() > if parent is missing. > > > Description: > > This is an idea to fix issue in bq27x00 driver (and probably in others) > reported by H. Nikolaus Schaller [0]. > > The fixes are marked RFC/RFT because: > 1. I do not have bq27x00-like device. I confirmed this and tested on > modified drivers (max77693, ACPI AC). These drivers are not > impacted by the issue but one can easily adjust them to reproduce > the problem. > 2. The first uevent coming from power_supply_register() is now > different because it won't contain device properties. I am > not sure how this impacts userspace. > > Comments are welcomed. appears to work! bq27000 is coming up now without hickups. What I can’t test is if the uevent is reasonable because we do not have a specific rule triggered by it in our system. So from my side we are now happy with the solution. Thanks and BR, Nikolaus > > > [0] https://lkml.org/lkml/2015/5/18/152 > > > Best regards, > Krzysztof > > Krzysztof Kozlowski (2): > power_supply: Fix NULL pointer dereference during bq27x00_battery >probe > power_supply: Fix possible NULL pointer dereference on early uevent > > drivers/power/power_supply_core.c | 61 +++ > include/linux/power_supply.h | 1 + > 2 files changed, 56 insertions(+), 6 deletions(-) > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/RFT v2 0/2] power_supply: Fix NULL pointer dereference from uevent
Hi, Am 19.05.2015 um 09:13 schrieb Krzysztof Kozlowski k.kozlow...@samsung.com: Hi, Changes since v1: = 1. Patch 2: fix invalid member used for container_of(). 2. Patch 2: Replace WARN with pr_warn() in __power_supply_register() if parent is missing. Description: This is an idea to fix issue in bq27x00 driver (and probably in others) reported by H. Nikolaus Schaller [0]. The fixes are marked RFC/RFT because: 1. I do not have bq27x00-like device. I confirmed this and tested on modified drivers (max77693, ACPI AC). These drivers are not impacted by the issue but one can easily adjust them to reproduce the problem. 2. The first uevent coming from power_supply_register() is now different because it won't contain device properties. I am not sure how this impacts userspace. Comments are welcomed. appears to work! bq27000 is coming up now without hickups. What I can’t test is if the uevent is reasonable because we do not have a specific rule triggered by it in our system. So from my side we are now happy with the solution. Thanks and BR, Nikolaus [0] https://lkml.org/lkml/2015/5/18/152 Best regards, Krzysztof Krzysztof Kozlowski (2): power_supply: Fix NULL pointer dereference during bq27x00_battery probe power_supply: Fix possible NULL pointer dereference on early uevent drivers/power/power_supply_core.c | 61 +++ include/linux/power_supply.h | 1 + 2 files changed, 56 insertions(+), 6 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug: power supply - NULL pointer dereference in bq27x00 driver
Am 18.05.2015 um 16:09 schrieb Krzysztof Kozlowski :
> 2015-05-18 22:30 GMT+09:00 Dr. H. Nikolaus Schaller :
>> Hi Krzysztof,
>>
>> Am 18.05.2015 um 14:32 schrieb Krzysztof Kozlowski :
>>
>>> 2015-05-18 18:40 GMT+09:00 Dr. H. Nikolaus Schaller :
>>>> Hi,
>>>> we tried to upgrade from 4.0 to 4.1-rc3 kernel and ran into a NULL pointer
>>>> problem within the bq27x00 driver.
>>>>
>>>> It appears to be introduced by your patch
>>>> 297d716f6260cc9421d971b124ca196b957ee458
>>>>
>>>> The problem appears to be that bq27x00_powersupply_init() calls
>>>> power_supply_register_no_ws() and
>>>> sets di->bat *after* return. The old code did pass an uninitialized struct
>>>> pointer.
>>>>
>>>> Now for reasons I don’t understand, the power_supply_register_no_ws()
>>>> appears to call
>>>> uevent related stuff which in turn calls bq27x00_battery_get_property()
>>>> before di->bat
>>>> is properly initialized.
>>>>
>>>> I have checked with printk in bq27x00_battery_get_property() that di>bat
>>>> == NULL in this case and
>>>> right before we see the segfault.
>>>>
>>>> The old code simply did pass a zeroed struct power_supply and perhaps
>>>> initialized its components
>>>> during registration.
>>>>
>>>> Returning some -EINVAL if di->bat == NULL would likely solve the NULL
>>>> pointer dereference but
>>>> I don’t know what it does to the uevent and if it restores previous
>>>> operation.
>>>>
>>>> It could have been that it was for good purpose that
>>>> power_supply_register_no_ws() did not return
>>>> by value, but by reference to the di->bat struct:
>>>>
>>>> - ret = power_supply_register_no_ws(di->dev, >bat, NULL);
>>>> + di->bat = power_supply_register_no_ws(di->dev, psy_desc, _cfg);
>>>>
>>>> So that code called within the context of power_supply_register_no_ws()
>>>> could already
>>>> refer to initialized di->bat.
>>>
>>> Indeed this issue was not present in previous design however I think
>>> the architecture was still error-prone. Starting from driver's probe:
>>> - some_driver_probe()
>>> - power_supply_register()
>>>- device_add()
>>> - kobject_uevent() - notify userspace
>>> - power_supply_uevent()
>>> - power_supply_show_property()
>>> - power_supply_get_property()
>>> - some_driver_get_property()
>>>
>>> So before probe() ends the power supply core calls driver's
>>> get_property(). In that time the driver internal structures may not be
>>> ready yet, because the probe did not end.
>>
>> Yes, that is indeed a problem. Maybe it did work with the bq27x00 driver
>> earlier because the call to power_supply_register() was the last
>> activity.
>
> Right, for most of the drivers it is the last part of probe.
>
>>
>>> The get_property() could
>>> access some registers or other core functions which will be ready
>>> after power_supply_register() call. For example the
>>> bq27x00_battery_get_property() accesses delayed work which could be
>>> (by mistake) not yet initialized.
>>>
>>> I looked at other dev_uevent implementations and almost all of them do
>>> not call back the driver.
>>>
>>> Of course this does not change that I introduced the issue and I feel
>>> bad about it.
>>> I got some ideas for resolving it:
>>> 1. Fix bq27x00_battery and maybe others so they won't access the 'psy'
>>> member of its state container. This does not solve the issue from
>>> architectural point of view - still some uninitialised data may be
>>> accessed because probe() is in progress. However this would be the
>>> fastest and the least intrusive.
>>
>> The problem might be that it fundamentally changes the driver code
>> architecture. For example one call using di->bat is in
>>
>> bq27x00_battery_status() {
>> …
>>else if (power_supply_am_i_supplied(di->bat))
>>status = POWER_SUPPLY_STATUS_NOT_CHARGING;
>> …
>> }
>>
>>>
>>> 2. Remove calls to get_property() (and other functions provided by
>>> driver) from power_supply_uevent(). U
Re: Bug: power supply - NULL pointer dereference in bq27x00 driver
Hi Krzysztof,
Am 18.05.2015 um 14:32 schrieb Krzysztof Kozlowski :
> 2015-05-18 18:40 GMT+09:00 Dr. H. Nikolaus Schaller :
>> Hi,
>> we tried to upgrade from 4.0 to 4.1-rc3 kernel and ran into a NULL pointer
>> problem within the bq27x00 driver.
>>
>> It appears to be introduced by your patch
>> 297d716f6260cc9421d971b124ca196b957ee458
>>
>> The problem appears to be that bq27x00_powersupply_init() calls
>> power_supply_register_no_ws() and
>> sets di->bat *after* return. The old code did pass an uninitialized struct
>> pointer.
>>
>> Now for reasons I don’t understand, the power_supply_register_no_ws()
>> appears to call
>> uevent related stuff which in turn calls bq27x00_battery_get_property()
>> before di->bat
>> is properly initialized.
>>
>> I have checked with printk in bq27x00_battery_get_property() that di>bat ==
>> NULL in this case and
>> right before we see the segfault.
>>
>> The old code simply did pass a zeroed struct power_supply and perhaps
>> initialized its components
>> during registration.
>>
>> Returning some -EINVAL if di->bat == NULL would likely solve the NULL
>> pointer dereference but
>> I don’t know what it does to the uevent and if it restores previous
>> operation.
>>
>> It could have been that it was for good purpose that
>> power_supply_register_no_ws() did not return
>> by value, but by reference to the di->bat struct:
>>
>> - ret = power_supply_register_no_ws(di->dev, >bat, NULL);
>> + di->bat = power_supply_register_no_ws(di->dev, psy_desc, _cfg);
>>
>> So that code called within the context of power_supply_register_no_ws()
>> could already
>> refer to initialized di->bat.
>
> Indeed this issue was not present in previous design however I think
> the architecture was still error-prone. Starting from driver's probe:
> - some_driver_probe()
> - power_supply_register()
> - device_add()
> - kobject_uevent() - notify userspace
>- power_supply_uevent()
> - power_supply_show_property()
>- power_supply_get_property()
> - some_driver_get_property()
>
> So before probe() ends the power supply core calls driver's
> get_property(). In that time the driver internal structures may not be
> ready yet, because the probe did not end.
Yes, that is indeed a problem. Maybe it did work with the bq27x00 driver
earlier because the call to power_supply_register() was the last
activity.
> The get_property() could
> access some registers or other core functions which will be ready
> after power_supply_register() call. For example the
> bq27x00_battery_get_property() accesses delayed work which could be
> (by mistake) not yet initialized.
>
> I looked at other dev_uevent implementations and almost all of them do
> not call back the driver.
>
> Of course this does not change that I introduced the issue and I feel
> bad about it.
> I got some ideas for resolving it:
> 1. Fix bq27x00_battery and maybe others so they won't access the 'psy'
> member of its state container. This does not solve the issue from
> architectural point of view - still some uninitialised data may be
> accessed because probe() is in progress. However this would be the
> fastest and the least intrusive.
The problem might be that it fundamentally changes the driver code
architecture. For example one call using di->bat is in
bq27x00_battery_status() {
…
else if (power_supply_am_i_supplied(di->bat))
status = POWER_SUPPLY_STATUS_NOT_CHARGING;
…
}
>
> 2. Remove calls to get_property() (and other functions provided by
> driver) from power_supply_uevent(). Unfortunately this may break
> userspace which expects that some data will be present in uevent.
>
> 3. Change the API to the previous convention, which you pointed as a remedy:
> ret = power_supply_register_no_ws(di->dev, >bat, psy_desc, _cfg);
> This also won't solve the issue from 1. that uevent will be called
> before probe ends.
Well, we could require that power_supply_register_no_ws() is the last
activity to be done in any_driver_probe().
>
> 4. Block the power_supply_uevent() from calling the get_property()
> functions until device_add() finishes. This would solve this issue but
> first uevent messages (from adding device) won't contain all of device
> data (just like in solution no 2.) and this won't solve other race -
> someone may call sysfs show() on created device nodes and thus access
> the get_property() before probe finishes.
>
> Any ideas?
5. is it possible to delay the call to kobject_ueve
Bug: power supply - NULL pointer dereference in bq27x00 driver
Hi, we tried to upgrade from 4.0 to 4.1-rc3 kernel and ran into a NULL pointer problem within the bq27x00 driver. It appears to be introduced by your patch 297d716f6260cc9421d971b124ca196b957ee458 The problem appears to be that bq27x00_powersupply_init() calls power_supply_register_no_ws() and sets di->bat *after* return. The old code did pass an uninitialized struct pointer. Now for reasons I don’t understand, the power_supply_register_no_ws() appears to call uevent related stuff which in turn calls bq27x00_battery_get_property() before di->bat is properly initialized. I have checked with printk in bq27x00_battery_get_property() that di>bat == NULL in this case and right before we see the segfault. The old code simply did pass a zeroed struct power_supply and perhaps initialized its components during registration. Returning some -EINVAL if di->bat == NULL would likely solve the NULL pointer dereference but I don’t know what it does to the uevent and if it restores previous operation. It could have been that it was for good purpose that power_supply_register_no_ws() did not return by value, but by reference to the di->bat struct: - ret = power_supply_register_no_ws(di->dev, >bat, NULL); + di->bat = power_supply_register_no_ws(di->dev, psy_desc, _cfg); So that code called within the context of power_supply_register_no_ws() could already refer to initialized di->bat. BR and thanks, Nikolaus Schaller [ 11.879943] Unable to handle kernel NULL pointer dereference at virtual address 000c [ 11.888519] pgd = c0004000 [ 11.891357] [000c] *pgd= [ 11.895141] Internal error: Oops: 5 [#1] SMP ARM [ 11.899963] Modules linked in: bq27x00_battery w1_bq27000 ov9655 v4l2_common omap_hdq snd_soc_omap_mcbsp videodev hmc5843_i2c(C) lis3lv02d_i2c snd_soc_omap lis3lv02d itg3200 snd_pcm_dmaengine tsc2007 bmp085_i2c bma150 hmc5843_core(C) media at24 input_polldev leds_tca6507 rtc_twl twl4030_pwrbutton twl4030_keypad twl4030_madc snd_soc_twl4030 twl4030_vibra ehci_omap [ 11.933898] CPU: 0 PID: 1164 Comm: w1_bus_master1 Tainted: G C 4.1.0-rc3-gta04+ #1086 [ 11.943267] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 11.949829] task: dd2729c0 ti: dd276000 task.ti: dd276000 [ 11.955505] PC is at __power_supply_is_supplied_by+0x8/0xc0 [ 11.961364] LR is at __power_supply_am_i_supplied+0x18/0x48 [ 11.967193] pc : []lr : []psr: a013 [ 11.967193] sp : dd277bb8 ip : fp : c092f82c [ 11.979217] r10: de348000 r9 : dd18cc20 r8 : dd18cc20 [ 11.984680] r7 : de5c9420 r6 : de5c9400 r5 : de5c9400 r4 : [ 11.991516] r3 : de5c9648 r2 : r1 : r0 : de5c9400 [ 11.998352] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 12.006011] Control: 10c5387d Table: 9c1b0019 DAC: 0015 [ 12.012054] Process w1_bus_master1 (pid: 1164, stack limit = 0xdd276218) [ 12.019073] Stack: (0xdd277bb8 to 0xdd278000) [ 12.023620] 7ba0: de5c9648 [ 12.032196] 7bc0: de5c9400 c046a040 de5c9420 c046a058 de5c9420 dd277bf4 [ 12.040771] 7be0: c0374ebc c05c4268 dd18eec4 dd18cc20 de27fea4 de5c9648 [ 12.049346] 7c00: dd18eee8 dd277c3c dd18ee10 dd18eec4 bf0d0de4 [ 12.057922] 7c20: dd377000 c092f82c dd18cc20 c0469508 b6db6db7 c046a140 dd18cc20 c092f82c [ 12.066467] 7c40: dd377000 dd18cc00 c046a42c dd18cc20 de348000 [ 12.075042] 7c60: c046a3b0 de348000 dd18cc28 dd18cc20 de0918c0 c0608dd8 [ 12.083618] 7c80: c07b5bb1 c0371f0c c07b5bb1 c02c72c4 de348000 dd277ca8 c07b5bb1 de348000 [ 12.092193] 7ca0: de348000 dd18cc28 c02c7544 0007 0006 c0083394 [ 12.100769] 7cc0: dd2729c0 dd2f6540 c07b2ae3 dc1f7950 dd18c810 dd18cc20 dd18cc28 [ 12.109344] 7ce0: dc1f7950 dd18c810 c0371938 dd18cc20 [ 12.117919] 7d00: c0008280 0080 dd18cc00 dd18cc20 dc1f7950 dd18c810 c0469cd8 [ 12.126464] 7d20: bf0d124f dd277d44 1f1c4000 c05ae99c bf0d124f dd18ee10 dc1f7950 bf0cc121 [ 12.135040] 7d40: 001b dd014c50 0001 bf0d0864 dd18ee10 [ 12.143615] 7d60: ffed dd18c810 bf0d1670 c03752c0 dd18c810 bf0d1670 c0373bd4 [ 12.152191] 7d80: 0007 dd18c810 bf0d1670 c0373ed8 c0373e34 dd18c810 [ 12.160766] 7da0: dd277da8 c037265c de0948d4 dd2f6194 dd18c810 dd18c810 dd18c844 dd18c810 [ 12.169342] 7dc0: bf0cc160 c0373dbc dd18c810 c0918590 dd18c810 c0373294 dd18c810 [ 12.177917] 7de0: dd18c818 c0371940 dd18c810 002f dd18c810 dd18c800 [ 12.186492] 7e00: bf0cc160 dd0144c0 c03754bc dd014c50 dd18c800 dd014c00 [ 12.195037] 7e20: bf0cc160 bf0cc058 dd014c00 dd014c00 bf0cc174 c04663c0 dd014c00 [ 12.203613] 7e40:
Re: Bug: power supply - NULL pointer dereference in bq27x00 driver
Hi Krzysztof,
Am 18.05.2015 um 14:32 schrieb Krzysztof Kozlowski k.kozlow...@samsung.com:
2015-05-18 18:40 GMT+09:00 Dr. H. Nikolaus Schaller h...@goldelico.com:
Hi,
we tried to upgrade from 4.0 to 4.1-rc3 kernel and ran into a NULL pointer
problem within the bq27x00 driver.
It appears to be introduced by your patch
297d716f6260cc9421d971b124ca196b957ee458
The problem appears to be that bq27x00_powersupply_init() calls
power_supply_register_no_ws() and
sets di-bat *after* return. The old code did pass an uninitialized struct
pointer.
Now for reasons I don’t understand, the power_supply_register_no_ws()
appears to call
uevent related stuff which in turn calls bq27x00_battery_get_property()
before di-bat
is properly initialized.
I have checked with printk in bq27x00_battery_get_property() that dibat ==
NULL in this case and
right before we see the segfault.
The old code simply did pass a zeroed struct power_supply and perhaps
initialized its components
during registration.
Returning some -EINVAL if di-bat == NULL would likely solve the NULL
pointer dereference but
I don’t know what it does to the uevent and if it restores previous
operation.
It could have been that it was for good purpose that
power_supply_register_no_ws() did not return
by value, but by reference to the di-bat struct:
- ret = power_supply_register_no_ws(di-dev, di-bat, NULL);
+ di-bat = power_supply_register_no_ws(di-dev, psy_desc, psy_cfg);
So that code called within the context of power_supply_register_no_ws()
could already
refer to initialized di-bat.
Indeed this issue was not present in previous design however I think
the architecture was still error-prone. Starting from driver's probe:
- some_driver_probe()
- power_supply_register(psy)
- device_add()
- kobject_uevent() - notify userspace
- power_supply_uevent()
- power_supply_show_property()
- power_supply_get_property()
- some_driver_get_property()
So before probe() ends the power supply core calls driver's
get_property(). In that time the driver internal structures may not be
ready yet, because the probe did not end.
Yes, that is indeed a problem. Maybe it did work with the bq27x00 driver
earlier because the call to power_supply_register(psy) was the last
activity.
The get_property() could
access some registers or other core functions which will be ready
after power_supply_register() call. For example the
bq27x00_battery_get_property() accesses delayed work which could be
(by mistake) not yet initialized.
I looked at other dev_uevent implementations and almost all of them do
not call back the driver.
Of course this does not change that I introduced the issue and I feel
bad about it.
I got some ideas for resolving it:
1. Fix bq27x00_battery and maybe others so they won't access the 'psy'
member of its state container. This does not solve the issue from
architectural point of view - still some uninitialised data may be
accessed because probe() is in progress. However this would be the
fastest and the least intrusive.
The problem might be that it fundamentally changes the driver code
architecture. For example one call using di-bat is in
bq27x00_battery_status() {
…
else if (power_supply_am_i_supplied(di-bat))
status = POWER_SUPPLY_STATUS_NOT_CHARGING;
…
}
2. Remove calls to get_property() (and other functions provided by
driver) from power_supply_uevent(). Unfortunately this may break
userspace which expects that some data will be present in uevent.
3. Change the API to the previous convention, which you pointed as a remedy:
ret = power_supply_register_no_ws(di-dev, di-bat, psy_desc, psy_cfg);
This also won't solve the issue from 1. that uevent will be called
before probe ends.
Well, we could require that power_supply_register_no_ws() is the last
activity to be done in any_driver_probe().
4. Block the power_supply_uevent() from calling the get_property()
functions until device_add() finishes. This would solve this issue but
first uevent messages (from adding device) won't contain all of device
data (just like in solution no 2.) and this won't solve other race -
someone may call sysfs show() on created device nodes and thus access
the get_property() before probe finishes.
Any ideas?
5. is it possible to delay the call to kobject_uevent() after
some_driver_probe()
is finished? E.g. by registering a one-shot delayed work?
There seems to be a shared workqueue (mentioned e.g. in
http://www.makelinux.net/ldd3/chp-7-sect-6)
but that is an area of the kernel I am not familiar with.
BR,
Nikolaus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bug: power supply - NULL pointer dereference in bq27x00 driver
Am 18.05.2015 um 16:09 schrieb Krzysztof Kozlowski k.kozlow...@samsung.com:
2015-05-18 22:30 GMT+09:00 Dr. H. Nikolaus Schaller h...@goldelico.com:
Hi Krzysztof,
Am 18.05.2015 um 14:32 schrieb Krzysztof Kozlowski k.kozlow...@samsung.com:
2015-05-18 18:40 GMT+09:00 Dr. H. Nikolaus Schaller h...@goldelico.com:
Hi,
we tried to upgrade from 4.0 to 4.1-rc3 kernel and ran into a NULL pointer
problem within the bq27x00 driver.
It appears to be introduced by your patch
297d716f6260cc9421d971b124ca196b957ee458
The problem appears to be that bq27x00_powersupply_init() calls
power_supply_register_no_ws() and
sets di-bat *after* return. The old code did pass an uninitialized struct
pointer.
Now for reasons I don’t understand, the power_supply_register_no_ws()
appears to call
uevent related stuff which in turn calls bq27x00_battery_get_property()
before di-bat
is properly initialized.
I have checked with printk in bq27x00_battery_get_property() that dibat
== NULL in this case and
right before we see the segfault.
The old code simply did pass a zeroed struct power_supply and perhaps
initialized its components
during registration.
Returning some -EINVAL if di-bat == NULL would likely solve the NULL
pointer dereference but
I don’t know what it does to the uevent and if it restores previous
operation.
It could have been that it was for good purpose that
power_supply_register_no_ws() did not return
by value, but by reference to the di-bat struct:
- ret = power_supply_register_no_ws(di-dev, di-bat, NULL);
+ di-bat = power_supply_register_no_ws(di-dev, psy_desc, psy_cfg);
So that code called within the context of power_supply_register_no_ws()
could already
refer to initialized di-bat.
Indeed this issue was not present in previous design however I think
the architecture was still error-prone. Starting from driver's probe:
- some_driver_probe()
- power_supply_register(psy)
- device_add()
- kobject_uevent() - notify userspace
- power_supply_uevent()
- power_supply_show_property()
- power_supply_get_property()
- some_driver_get_property()
So before probe() ends the power supply core calls driver's
get_property(). In that time the driver internal structures may not be
ready yet, because the probe did not end.
Yes, that is indeed a problem. Maybe it did work with the bq27x00 driver
earlier because the call to power_supply_register(psy) was the last
activity.
Right, for most of the drivers it is the last part of probe.
The get_property() could
access some registers or other core functions which will be ready
after power_supply_register() call. For example the
bq27x00_battery_get_property() accesses delayed work which could be
(by mistake) not yet initialized.
I looked at other dev_uevent implementations and almost all of them do
not call back the driver.
Of course this does not change that I introduced the issue and I feel
bad about it.
I got some ideas for resolving it:
1. Fix bq27x00_battery and maybe others so they won't access the 'psy'
member of its state container. This does not solve the issue from
architectural point of view - still some uninitialised data may be
accessed because probe() is in progress. However this would be the
fastest and the least intrusive.
The problem might be that it fundamentally changes the driver code
architecture. For example one call using di-bat is in
bq27x00_battery_status() {
…
else if (power_supply_am_i_supplied(di-bat))
status = POWER_SUPPLY_STATUS_NOT_CHARGING;
…
}
2. Remove calls to get_property() (and other functions provided by
driver) from power_supply_uevent(). Unfortunately this may break
userspace which expects that some data will be present in uevent.
3. Change the API to the previous convention, which you pointed as a remedy:
ret = power_supply_register_no_ws(di-dev, di-bat, psy_desc, psy_cfg);
This also won't solve the issue from 1. that uevent will be called
before probe ends.
Well, we could require that power_supply_register_no_ws() is the last
activity to be done in any_driver_probe().
Some drivers (like drivers/power/lp8727_charger.c) register multiple
power supplies and there can be only one last call. What is even
important in this lp8727 case, is that it registers:
- a battery,
- two chargers which supply this battery.
So when power supplies are registered, the delayed work is executed
for each supplied battery. Hopefully the the battery is registered as
last... but I am not quite sure that this is still safe.
4. Block the power_supply_uevent() from calling the get_property()
functions until device_add() finishes. This would solve this issue but
first uevent messages (from adding device) won't contain all of device
data (just like in solution no 2.) and this won't solve other race -
someone may call sysfs show
Bug: power supply - NULL pointer dereference in bq27x00 driver
Hi, we tried to upgrade from 4.0 to 4.1-rc3 kernel and ran into a NULL pointer problem within the bq27x00 driver. It appears to be introduced by your patch 297d716f6260cc9421d971b124ca196b957ee458 The problem appears to be that bq27x00_powersupply_init() calls power_supply_register_no_ws() and sets di-bat *after* return. The old code did pass an uninitialized struct pointer. Now for reasons I don’t understand, the power_supply_register_no_ws() appears to call uevent related stuff which in turn calls bq27x00_battery_get_property() before di-bat is properly initialized. I have checked with printk in bq27x00_battery_get_property() that dibat == NULL in this case and right before we see the segfault. The old code simply did pass a zeroed struct power_supply and perhaps initialized its components during registration. Returning some -EINVAL if di-bat == NULL would likely solve the NULL pointer dereference but I don’t know what it does to the uevent and if it restores previous operation. It could have been that it was for good purpose that power_supply_register_no_ws() did not return by value, but by reference to the di-bat struct: - ret = power_supply_register_no_ws(di-dev, di-bat, NULL); + di-bat = power_supply_register_no_ws(di-dev, psy_desc, psy_cfg); So that code called within the context of power_supply_register_no_ws() could already refer to initialized di-bat. BR and thanks, Nikolaus Schaller [ 11.879943] Unable to handle kernel NULL pointer dereference at virtual address 000c [ 11.888519] pgd = c0004000 [ 11.891357] [000c] *pgd= [ 11.895141] Internal error: Oops: 5 [#1] SMP ARM [ 11.899963] Modules linked in: bq27x00_battery w1_bq27000 ov9655 v4l2_common omap_hdq snd_soc_omap_mcbsp videodev hmc5843_i2c(C) lis3lv02d_i2c snd_soc_omap lis3lv02d itg3200 snd_pcm_dmaengine tsc2007 bmp085_i2c bma150 hmc5843_core(C) media at24 input_polldev leds_tca6507 rtc_twl twl4030_pwrbutton twl4030_keypad twl4030_madc snd_soc_twl4030 twl4030_vibra ehci_omap [ 11.933898] CPU: 0 PID: 1164 Comm: w1_bus_master1 Tainted: G C 4.1.0-rc3-gta04+ #1086 [ 11.943267] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 11.949829] task: dd2729c0 ti: dd276000 task.ti: dd276000 [ 11.955505] PC is at __power_supply_is_supplied_by+0x8/0xc0 [ 11.961364] LR is at __power_supply_am_i_supplied+0x18/0x48 [ 11.967193] pc : [c0469f4c]lr : [c046a058]psr: a013 [ 11.967193] sp : dd277bb8 ip : fp : c092f82c [ 11.979217] r10: de348000 r9 : dd18cc20 r8 : dd18cc20 [ 11.984680] r7 : de5c9420 r6 : de5c9400 r5 : de5c9400 r4 : [ 11.991516] r3 : de5c9648 r2 : r1 : r0 : de5c9400 [ 11.998352] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 12.006011] Control: 10c5387d Table: 9c1b0019 DAC: 0015 [ 12.012054] Process w1_bus_master1 (pid: 1164, stack limit = 0xdd276218) [ 12.019073] Stack: (0xdd277bb8 to 0xdd278000) [ 12.023620] 7ba0: de5c9648 [ 12.032196] 7bc0: de5c9400 c046a040 de5c9420 c046a058 de5c9420 dd277bf4 [ 12.040771] 7be0: c0374ebc c05c4268 dd18eec4 dd18cc20 de27fea4 de5c9648 [ 12.049346] 7c00: dd18eee8 dd277c3c dd18ee10 dd18eec4 bf0d0de4 [ 12.057922] 7c20: dd377000 c092f82c dd18cc20 c0469508 b6db6db7 c046a140 dd18cc20 c092f82c [ 12.066467] 7c40: dd377000 dd18cc00 c046a42c dd18cc20 de348000 [ 12.075042] 7c60: c046a3b0 de348000 dd18cc28 dd18cc20 de0918c0 c0608dd8 [ 12.083618] 7c80: c07b5bb1 c0371f0c c07b5bb1 c02c72c4 de348000 dd277ca8 c07b5bb1 de348000 [ 12.092193] 7ca0: de348000 dd18cc28 c02c7544 0007 0006 c0083394 [ 12.100769] 7cc0: dd2729c0 dd2f6540 c07b2ae3 dc1f7950 dd18c810 dd18cc20 dd18cc28 [ 12.109344] 7ce0: dc1f7950 dd18c810 c0371938 dd18cc20 [ 12.117919] 7d00: c0008280 0080 dd18cc00 dd18cc20 dc1f7950 dd18c810 c0469cd8 [ 12.126464] 7d20: bf0d124f dd277d44 1f1c4000 c05ae99c bf0d124f dd18ee10 dc1f7950 bf0cc121 [ 12.135040] 7d40: 001b dd014c50 0001 bf0d0864 dd18ee10 [ 12.143615] 7d60: ffed dd18c810 bf0d1670 c03752c0 dd18c810 bf0d1670 c0373bd4 [ 12.152191] 7d80: 0007 dd18c810 bf0d1670 c0373ed8 c0373e34 dd18c810 [ 12.160766] 7da0: dd277da8 c037265c de0948d4 dd2f6194 dd18c810 dd18c810 dd18c844 dd18c810 [ 12.169342] 7dc0: bf0cc160 c0373dbc dd18c810 c0918590 dd18c810 c0373294 dd18c810 [ 12.177917] 7de0: dd18c818 c0371940 dd18c810 002f dd18c810 dd18c800 [ 12.186492] 7e00: bf0cc160 dd0144c0 c03754bc dd014c50 dd18c800 dd014c00 [ 12.195037] 7e20: bf0cc160 bf0cc058 dd014c00 dd014c00 bf0cc174 c04663c0 dd014c00 [ 12.203613]
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Peter, Am 07.05.2015 um 18:46 schrieb Dr. H. Nikolaus Schaller : > Hi Peter, > > Am 07.05.2015 um 17:51 schrieb Peter Hurley : > >> On 05/07/2015 11:34 AM, Dr. H. Nikolaus Schaller wrote: >>> Am 07.05.2015 um 16:56 schrieb Peter Hurley : >>>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote: >> >>>> Both devicetree and tty/serial can already represent independent control; >>>> what is proposed is a way to express dependent control, and in all cases, >>>> that control stems directly from either the UART state itself or via >>>> commands sent over that interface. >>> >>> Yes. This is why I propose that the tty/uart driver can send an internal >>> notification >>> to the device driver. And the device driver can register to be notified by >>> the UART >>> that is identified by the phandle of the slave DT entry. >> >> I've not seen any code with your proposal, so that makes it impossible to >> compare competing solutions. > > If you can give me some (unspecified) time to do it, I can write (simplified) > patches > to demonstrate the idea. > > I just hesitate to work out and submit a counter proposal to what Neil has > submitted, > because it will become wasted effort if it is rejected before I am finished. We have progress and some code on our workbench that identifies the uart_port by phandle, resolves probing sequence and intercepts uart_update_mctrl calls. So we can let the attached slave driver know that the DTR line has changed, which is typically the power-on/off signal on UART/RS232. The driver can then power manage the device as needed (GPIO state, GPIO pulses, regulator, I2C or whatever). What we have not yet solved is the issue that a slave driver might want to know that the controlled slave device is active (i.e. is autonomously sending data to the UART). Even if the tty is not open. But we have an rough idea how we want to solve that. Patches will come asap. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Peter, Am 07.05.2015 um 18:46 schrieb Dr. H. Nikolaus Schaller h...@goldelico.com: Hi Peter, Am 07.05.2015 um 17:51 schrieb Peter Hurley pe...@hurleysoftware.com: On 05/07/2015 11:34 AM, Dr. H. Nikolaus Schaller wrote: Am 07.05.2015 um 16:56 schrieb Peter Hurley pe...@hurleysoftware.com: On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote: Both devicetree and tty/serial can already represent independent control; what is proposed is a way to express dependent control, and in all cases, that control stems directly from either the UART state itself or via commands sent over that interface. Yes. This is why I propose that the tty/uart driver can send an internal notification to the device driver. And the device driver can register to be notified by the UART that is identified by the phandle of the slave DT entry. I've not seen any code with your proposal, so that makes it impossible to compare competing solutions. If you can give me some (unspecified) time to do it, I can write (simplified) patches to demonstrate the idea. I just hesitate to work out and submit a counter proposal to what Neil has submitted, because it will become wasted effort if it is rejected before I am finished. We have progress and some code on our workbench that identifies the uart_port by phandle, resolves probing sequence and intercepts uart_update_mctrl calls. So we can let the attached slave driver know that the DTR line has changed, which is typically the power-on/off signal on UART/RS232. The driver can then power manage the device as needed (GPIO state, GPIO pulses, regulator, I2C or whatever). What we have not yet solved is the issue that a slave driver might want to know that the controlled slave device is active (i.e. is autonomously sending data to the UART). Even if the tty is not open. But we have an rough idea how we want to solve that. Patches will come asap. BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi,
Am 07.05.2015 um 18:18 schrieb Peter Hurley :
> On 05/07/2015 11:11 AM, Dr. H. Nikolaus Schaller wrote:
>>
>> Am 07.05.2015 um 16:30 schrieb Peter Hurley :
>>
>>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
>>>> Am 06.05.2015 um 19:18 schrieb Mark Rutland :
>>>>> On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
>>>>>> Am 06.05.2015 um 16:15 schrieb Mark Rutland :
>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>>> If this happens, you can move the slave device into a fragment that
>>>>>>>>> you
>>>>>>>>> can include under the correct node. That's trivial.
>>>>>>>>
>>>>>>>> But less readable. And that is important as well.
>>>>>>>
>>>>>>> I disagree. The manipulation you have to perform to override properties
>>>>>>> is at least as bad as including a file.
>>>>>>
>>>>>> What about:
>>>>>>
>>>>>> #include "omap3-beagle-xm.dts"
>>>>>>
>>>>>> / {
>>>>>> /* HS USB Port 2 Power enable was inverted with the xM C */
>>>>>> hsusb2_power: hsusb2_power_reg {
>>>>>> enable-active-high;
>>>>>> };
>>>>>> };
>>>>>>
>>>>>> compared to
>>>>>>
>>>>>> #include “board1.dts”
>>>>>>
>>>>>> / {
>>>>>> /* slave was reconnected to uart4 */
>>>>>> slave {
>>>>>> uart = <>;
>>>>>> };
>>>>>> };
>>>>>
>>>>> As I mentioned, you can easily carve up your DTS to make that work with
>>>>> includes if you really must:
>>>>>
>>>>> /* UART0 board variant */
>>>>> #include "board.dtsi"
>>>>> {
>>>>> #include "some-uart-slave.dtsi"
>>>>> };
>>>>>
>>>>> /* UART1 board variant */
>>>>> #include "board.dtsi"
>>>>> {
>>>>> #include "some-uart-slave.dtsi"
>>>>> };
>>>>>
>>>>> If you happen to find includes ugly then you can say it's ugly, but it's
>>>>> functionally equivalent, and also means you can avoid having
>>>>> disabled/partial nodes all over the place.
>>>>
>>>> Functionally equivalent would also be to copy the whole source file and
>>>> s///.
>>>>
>>>> But this is not the best solution for the DT programmer since there is no
>>>> automatic *reuse* of common parts.
>>>>
>>>> And your proposal requires 3 source files instead of 2 which deteriorates
>>>> readibility and understanding what is really going on. And if you need to
>>>> change the some-uart-slave, you have to touch a different file than for
>>>> changing some other slave.
>>>>
>>>> Yes, it works, but IMHO other factors for a good design are also important.
>>>>
>>>> Maybe our main difference in PoV is that I specifically want to avoid that
>>>> we force future DT programmers into “ugly” solutions (even if they work).
>>>>
>>>> If you think that DT programmers have to live with what they are
>>>> given and do the best with it, we can end the discussion.
>>>
>>> The question of syntax is orthogonal to the discussion of the proper
>>> devicetree representation.
>>>
>>> The awkwardness of expressing v
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Peter, Am 07.05.2015 um 17:51 schrieb Peter Hurley : > On 05/07/2015 11:34 AM, Dr. H. Nikolaus Schaller wrote: >> Am 07.05.2015 um 16:56 schrieb Peter Hurley : >>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote: > >>> Both devicetree and tty/serial can already represent independent control; >>> what is proposed is a way to express dependent control, and in all cases, >>> that control stems directly from either the UART state itself or via >>> commands sent over that interface. >> >> Yes. This is why I propose that the tty/uart driver can send an internal >> notification >> to the device driver. And the device driver can register to be notified by >> the UART >> that is identified by the phandle of the slave DT entry. > > I've not seen any code with your proposal, so that makes it impossible to > compare competing solutions. If you can give me some (unspecified) time to do it, I can write (simplified) patches to demonstrate the idea. I just hesitate to work out and submit a counter proposal to what Neil has submitted, because it will become wasted effort if it is rejected before I am finished. > > >>> Any target not requiring UART involvement doesn't (and probably, shouldn't) >>> be expressed as a slave device. >> >> IMHO it is not obligatory to represent the direction of control by a >> parent>child >> relation in DT. DT just needs to describe that there is a >> relation/connection. > > Devicetree usage in the linux kernel is for representing the host view, not an > abstract machine. I have yet to see an example of a proposed tty slave where > the > host interface is not a UART. So far, I am only aware of two devices proposed to be tty power controlled slaves: * our GPS chip and * several Bluetooth modules (using HCI). It is difficult to predict future use cases and systems. With some phantasy there could be some I2C controlled serial level shifter that translates uart RX/TX/RTS/CTS to RS232 levels but allows for pin swapping (null modem). Power control of that chip is done through I2C. Similar chips exist for headset pinout detection ans automatic swapping, e.g. TS3A225E. Or some Infrared (IrDA) transceiver with mode and power control over I2C. Such a device should probably be described as a child node of the I2C bus it is connected to. And the driver must become an i2c device driver. So this would be in conflict with tty slave child nodes - but no problem with a phandle to the uart. > >> The driver code already must “know” the direction of notifications. >> >> BTW, there can even be control in reverse direction in some cases. E.g. the >> slave >> driver wants to automatically set the baud rate of the uart, i.e. the slave >> controls >> the uart on /dev/tty side. >> >> If I have monitored some other discussion right, this is exactly done by a >> Codec >> driver to tell its mcbsp counterpart about clock rates and data formats it >> should >> expect. Maybe this is the reason why McBSP use (or are just happy with) the >> phandle approach. > > Parameters are not control. Agreed. Especially if you mean power control. But does it change the necessity to describe the control direction in the DT as parent>child? In many other situations power control is described by regulator phandles and the regulators are not children of the controlling DT node. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Am 07.05.2015 um 16:56 schrieb Peter Hurley : > On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote: > >> So I don’t think that being able to control the slave is a common property >> of all UART-slave connections. >> >> BTW: the GPS chip we use is doing something without any instructions. It >> starts >> to send NMEA records right after power on. It would even be useful with a >> unidirectional >> connection from GPS to UART. Hence there are no commands that need to be >> sent through UART. Rather it just needs some GPIO to be activated or powered >> down >> when /dev/tty is opened/closed. > > In this example, the GPIO is a workaround for the lack of DTR. Yes. Our long ago proposal was to use DTR - but this did lead to make the GPS driver present a “virtual gpio”, that could have been plumbed to a dtr-gpio phandle of the uart driver. The only reason is that some piece of code must pulse-shape the DTR to be fed into the real GPS control pin.0 But I agree that we should not have such “virtual gpios”, since they are not needed (in either approach we discuss now). > > >> So one could argue that in this real case (which we try to solve in an >> acceptable way >> since 2 years) the fundamental/main interface (control command interface) of >> this chip >> is the power on/off line. And UART isn’t involved at all. Or just as an >> “activity detector”. > > The indirect nature of control in this case only reflects the workaround, > not the underlying concept. Control is still derived from the UART status. > > Both devicetree and tty/serial can already represent independent control; > what is proposed is a way to express dependent control, and in all cases, > that control stems directly from either the UART state itself or via > commands sent over that interface. Yes. This is why I propose that the tty/uart driver can send an internal notification to the device driver. And the device driver can register to be notified by the UART that is identified by the phandle of the slave DT entry. > > Any target not requiring UART involvement doesn't (and probably, shouldn't) > be expressed as a slave device. IMHO it is not obligatory to represent the direction of control by a parent>child relation in DT. DT just needs to describe that there is a relation/connection. The driver code already must “know” the direction of notifications. BTW, there can even be control in reverse direction in some cases. E.g. the slave driver wants to automatically set the baud rate of the uart, i.e. the slave controls the uart on /dev/tty side. If I have monitored some other discussion right, this is exactly done by a Codec driver to tell its mcbsp counterpart about clock rates and data formats it should expect. Maybe this is the reason why McBSP use (or are just happy with) the phandle approach. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Am 07.05.2015 um 16:30 schrieb Peter Hurley :
> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
>> Am 06.05.2015 um 19:18 schrieb Mark Rutland :
>>> On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
>>>> Am 06.05.2015 um 16:15 schrieb Mark Rutland :
>>>>
>>>>>>>>>> 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.
>>>>>
>>>>> [...]
>>>>>
>>>>>>> If this happens, you can move the slave device into a fragment that you
>>>>>>> can include under the correct node. That's trivial.
>>>>>>
>>>>>> But less readable. And that is important as well.
>>>>>
>>>>> I disagree. The manipulation you have to perform to override properties
>>>>> is at least as bad as including a file.
>>>>
>>>> What about:
>>>>
>>>> #include "omap3-beagle-xm.dts"
>>>>
>>>> / {
>>>>/* HS USB Port 2 Power enable was inverted with the xM C */
>>>>hsusb2_power: hsusb2_power_reg {
>>>>enable-active-high;
>>>>};
>>>> };
>>>>
>>>> compared to
>>>>
>>>> #include “board1.dts”
>>>>
>>>> / {
>>>>/* slave was reconnected to uart4 */
>>>>slave {
>>>>uart = <>;
>>>>};
>>>> };
>>>
>>> As I mentioned, you can easily carve up your DTS to make that work with
>>> includes if you really must:
>>>
>>> /* UART0 board variant */
>>> #include "board.dtsi"
>>> {
>>> #include "some-uart-slave.dtsi"
>>> };
>>>
>>> /* UART1 board variant */
>>> #include "board.dtsi"
>>> {
>>> #include "some-uart-slave.dtsi"
>>> };
>>>
>>> If you happen to find includes ugly then you can say it's ugly, but it's
>>> functionally equivalent, and also means you can avoid having
>>> disabled/partial nodes all over the place.
>>
>> Functionally equivalent would also be to copy the whole source file and
>> s///.
>>
>> But this is not the best solution for the DT programmer since there is no
>> automatic *reuse* of common parts.
>>
>> And your proposal requires 3 source files instead of 2 which deteriorates
>> readibility and understanding what is really going on. And if you need to
>> change the some-uart-slave, you have to touch a different file than for
>> changing some other slave.
>>
>> Yes, it works, but IMHO other factors for a good design are also important.
>>
>> Maybe our main difference in PoV is that I specifically want to avoid that
>> we force future DT programmers into “ugly” solutions (even if they work).
>>
>> If you think that DT programmers have to live with what they are
>> given and do the best with it, we can end the discussion.
>
> The question of syntax is orthogonal to the discussion of the proper
> devicetree representation.
>
> The awkwardness of expressing variants has nothing to do with the
> appropriate device hierarchy (or whether there should be a hierarchy).
> Describing variants is just as awkward when the parent-child relationship
> is indisputable.
That is ok. But I still have not found the key rule when a parent-child
relationship
is indisputable. Candidates so far are “main interface” (which is still
disputable)
or “bus” (where we can dispute if a point-to-point connection is a “bus”).
But if both options are equally valid (maybe because there is no rule
making either indisputable), I would chose the one with easier syntax.
>
> There was a recent discussion on devicetree ML regarding how best to
> express and represent variance. Feel free to revive that discussion.
Does it help? Our core issue is not the syntax and variance per se. This are
just examples to demonstrate differences in syntax of parent-child vs. phandle.
If we decide for either one, we have to live with syntactical and other
implcationd.
BR,
Nikolaus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Mark,
Am 06.05.2015 um 19:18 schrieb Mark Rutland :
> On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
>> Hi Mark,
>>
>> Am 06.05.2015 um 16:15 schrieb Mark Rutland :
>>
>>>>>>>> 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.
>>>
>>> [...]
>>>
>>>>> If this happens, you can move the slave device into a fragment that you
>>>>> can include under the correct node. That's trivial.
>>>>
>>>> But less readable. And that is important as well.
>>>
>>> I disagree. The manipulation you have to perform to override properties
>>> is at least as bad as including a file.
>>
>> What about:
>>
>> #include "omap3-beagle-xm.dts"
>>
>> / {
>> /* HS USB Port 2 Power enable was inverted with the xM C */
>> hsusb2_power: hsusb2_power_reg {
>> enable-active-high;
>> };
>> };
>>
>> compared to
>>
>> #include “board1.dts”
>>
>> / {
>> /* slave was reconnected to uart4 */
>> slave {
>> uart = <>;
>> };
>> };
>
> As I mentioned, you can easily carve up your DTS to make that work with
> includes if you really must:
>
> /* UART0 board variant */
> #include "board.dtsi"
> {
> #include "some-uart-slave.dtsi"
> };
>
> /* UART1 board variant */
> #include "board.dtsi"
> {
> #include "some-uart-slave.dtsi"
> };
>
> If you happen to find includes ugly then you can say it's ugly, but it's
> functionally equivalent, and also means you can avoid having
> disabled/partial nodes all over the place.
Functionally equivalent would also be to copy the whole source file and
s///.
But this is not the best solution for the DT programmer since there is no
automatic *reuse* of common parts.
And your proposal requires 3 source files instead of 2 which deteriorates
readibility and understanding what is really going on. And if you need to
change the some-uart-slave, you have to touch a different file than for
changing some other slave.
Yes, it works, but IMHO other factors for a good design are also important.
Maybe our main difference in PoV is that I specifically want to avoid that
we force future DT programmers into “ugly” solutions (even if they work).
If you think that DT programmers have to live with what they are
given and do the best with it, we can end the discussion.
>
> If you really wanted you could macro the label instead and have the
> slaved node in full.
Hm. I have tried to find a single example where a DT source file has an
#include *not* on top level. Or a macro that defines multiple properties
or a complete subnode.
Maybe it is a commonly used DT design pattern and I just didn’t find it
in the device trees I have checked.
>
> [...]
>
>>> As Neil mentioned earlier, ignore "bus". Here we're caring about a 1-1
>>> connection between master (UART) and slave (device), and it happens that
>>> in most other cases the master is actually a bus, so that's how things
>>> happen to be named.
>>
>> So you also mean that all master-slave connections must be represented
>> by DT subnodes and everything else is not acceptable?
>>
>> What about:
>>
>> sound {
>> compatible = "ti,omap-twl4030";
>> ti,model = "omap3beagle";
>>
>> ti,mcbsp = <>;
>> };
>>
>> Isn’t McBSP a “bus” with your definition as well? Like a “master”. And the
>> “twl4030”
>> is the slave (codec)?
>
> I'm nowhere near familiar enough with the audio hardware nor their
> bindings to comment on that, I'm afraid. My rough understanding was that
> the twl4030 node here was referring to the logical subsystem as a whole,
> with the mcbsp being a physical component, but that's almost certainly
> somewhat wrong.
The McBSP is a 4-wire serial interface controller sitting on the OMAP chip.
It is accessed by MMIO and DMA. The twl4030 is the other end and the data
that is transferr
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Mark,
Am 06.05.2015 um 19:18 schrieb Mark Rutland mark.rutl...@arm.com:
On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
Hi Mark,
Am 06.05.2015 um 16:15 schrieb Mark Rutland mark.rutl...@arm.com:
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.
[...]
If this happens, you can move the slave device into a fragment that you
can include under the correct node. That's trivial.
But less readable. And that is important as well.
I disagree. The manipulation you have to perform to override properties
is at least as bad as including a file.
What about:
#include omap3-beagle-xm.dts
/ {
/* HS USB Port 2 Power enable was inverted with the xM C */
hsusb2_power: hsusb2_power_reg {
enable-active-high;
};
};
compared to
#include “board1.dts”
/ {
/* slave was reconnected to uart4 */
slave {
uart = uart4;
};
};
As I mentioned, you can easily carve up your DTS to make that work with
includes if you really must:
/* UART0 board variant */
#include board.dtsi
uart0 {
#include some-uart-slave.dtsi
};
/* UART1 board variant */
#include board.dtsi
uart1 {
#include some-uart-slave.dtsi
};
If you happen to find includes ugly then you can say it's ugly, but it's
functionally equivalent, and also means you can avoid having
disabled/partial nodes all over the place.
Functionally equivalent would also be to copy the whole source file and
s/uart0/uart1/.
But this is not the best solution for the DT programmer since there is no
automatic *reuse* of common parts.
And your proposal requires 3 source files instead of 2 which deteriorates
readibility and understanding what is really going on. And if you need to
change the some-uart-slave, you have to touch a different file than for
changing some other slave.
Yes, it works, but IMHO other factors for a good design are also important.
Maybe our main difference in PoV is that I specifically want to avoid that
we force future DT programmers into “ugly” solutions (even if they work).
If you think that DT programmers have to live with what they are
given and do the best with it, we can end the discussion.
If you really wanted you could macro the label instead and have the
slaved node in full.
Hm. I have tried to find a single example where a DT source file has an
#include *not* on top level. Or a macro that defines multiple properties
or a complete subnode.
Maybe it is a commonly used DT design pattern and I just didn’t find it
in the device trees I have checked.
[...]
As Neil mentioned earlier, ignore bus. Here we're caring about a 1-1
connection between master (UART) and slave (device), and it happens that
in most other cases the master is actually a bus, so that's how things
happen to be named.
So you also mean that all master-slave connections must be represented
by DT subnodes and everything else is not acceptable?
What about:
sound {
compatible = ti,omap-twl4030;
ti,model = omap3beagle;
ti,mcbsp = mcbsp2;
};
Isn’t McBSP a “bus” with your definition as well? Like a “master”. And the
“twl4030”
is the slave (codec)?
I'm nowhere near familiar enough with the audio hardware nor their
bindings to comment on that, I'm afraid. My rough understanding was that
the twl4030 node here was referring to the logical subsystem as a whole,
with the mcbsp being a physical component, but that's almost certainly
somewhat wrong.
The McBSP is a 4-wire serial interface controller sitting on the OMAP chip.
It is accessed by MMIO and DMA. The twl4030 is the other end and the data
that is transferred is PCM audio to/from speakers/microphone.
So this node defines: there is a sound slave that is a twl4030 and the PCM
interface
is the mcbsp2 of the OMAP SoC. Exactly the same pattern as I want to describe
a GPS slave that is connected to uart1 of the OMAP SoC.
usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
phys = usb2_phy;
phy-names = usb2-phy;
mode = 3;
power = 50;
};
Isn’t a PHY interface (e.g. ULPI-PHY) a “slave” connected to a 12 wire ULPI
“bus” as well?
Not necessarily. If you took a look at the bindings you'd notice that
many PHYs have MMIO interfaces for configuration which we have to poke.
Those MMIO interfaces live on an MMIO bus so we describe those and link
to the phy by phandle reference.
Yes, that is the reason why it can only be solved by a phandle, because the
“main interface”
of the PHY chip is sometimes the MMIO bus, but could also be I2C or SPI.
In the case of osb_otg_hs I have copied
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Am 07.05.2015 um 16:30 schrieb Peter Hurley pe...@hurleysoftware.com:
On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
Am 06.05.2015 um 19:18 schrieb Mark Rutland mark.rutl...@arm.com:
On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
Am 06.05.2015 um 16:15 schrieb Mark Rutland mark.rutl...@arm.com:
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.
[...]
If this happens, you can move the slave device into a fragment that you
can include under the correct node. That's trivial.
But less readable. And that is important as well.
I disagree. The manipulation you have to perform to override properties
is at least as bad as including a file.
What about:
#include omap3-beagle-xm.dts
/ {
/* HS USB Port 2 Power enable was inverted with the xM C */
hsusb2_power: hsusb2_power_reg {
enable-active-high;
};
};
compared to
#include “board1.dts”
/ {
/* slave was reconnected to uart4 */
slave {
uart = uart4;
};
};
As I mentioned, you can easily carve up your DTS to make that work with
includes if you really must:
/* UART0 board variant */
#include board.dtsi
uart0 {
#include some-uart-slave.dtsi
};
/* UART1 board variant */
#include board.dtsi
uart1 {
#include some-uart-slave.dtsi
};
If you happen to find includes ugly then you can say it's ugly, but it's
functionally equivalent, and also means you can avoid having
disabled/partial nodes all over the place.
Functionally equivalent would also be to copy the whole source file and
s/uart0/uart1/.
But this is not the best solution for the DT programmer since there is no
automatic *reuse* of common parts.
And your proposal requires 3 source files instead of 2 which deteriorates
readibility and understanding what is really going on. And if you need to
change the some-uart-slave, you have to touch a different file than for
changing some other slave.
Yes, it works, but IMHO other factors for a good design are also important.
Maybe our main difference in PoV is that I specifically want to avoid that
we force future DT programmers into “ugly” solutions (even if they work).
If you think that DT programmers have to live with what they are
given and do the best with it, we can end the discussion.
The question of syntax is orthogonal to the discussion of the proper
devicetree representation.
The awkwardness of expressing variants has nothing to do with the
appropriate device hierarchy (or whether there should be a hierarchy).
Describing variants is just as awkward when the parent-child relationship
is indisputable.
That is ok. But I still have not found the key rule when a parent-child
relationship
is indisputable. Candidates so far are “main interface” (which is still
disputable)
or “bus” (where we can dispute if a point-to-point connection is a “bus”).
But if both options are equally valid (maybe because there is no rule
making either indisputable), I would chose the one with easier syntax.
There was a recent discussion on devicetree ML regarding how best to
express and represent variance. Feel free to revive that discussion.
Does it help? Our core issue is not the syntax and variance per se. This are
just examples to demonstrate differences in syntax of parent-child vs. phandle.
If we decide for either one, we have to live with syntactical and other
implcationd.
BR,
Nikolaus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Am 07.05.2015 um 16:56 schrieb Peter Hurley pe...@hurleysoftware.com: On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote: So I don’t think that being able to control the slave is a common property of all UART-slave connections. BTW: the GPS chip we use is doing something without any instructions. It starts to send NMEA records right after power on. It would even be useful with a unidirectional connection from GPS to UART. Hence there are no commands that need to be sent through UART. Rather it just needs some GPIO to be activated or powered down when /dev/tty is opened/closed. In this example, the GPIO is a workaround for the lack of DTR. Yes. Our long ago proposal was to use DTR - but this did lead to make the GPS driver present a “virtual gpio”, that could have been plumbed to a dtr-gpio phandle of the uart driver. The only reason is that some piece of code must pulse-shape the DTR to be fed into the real GPS control pin.0 But I agree that we should not have such “virtual gpios”, since they are not needed (in either approach we discuss now). So one could argue that in this real case (which we try to solve in an acceptable way since 2 years) the fundamental/main interface (control command interface) of this chip is the power on/off line. And UART isn’t involved at all. Or just as an “activity detector”. The indirect nature of control in this case only reflects the workaround, not the underlying concept. Control is still derived from the UART status. Both devicetree and tty/serial can already represent independent control; what is proposed is a way to express dependent control, and in all cases, that control stems directly from either the UART state itself or via commands sent over that interface. Yes. This is why I propose that the tty/uart driver can send an internal notification to the device driver. And the device driver can register to be notified by the UART that is identified by the phandle of the slave DT entry. Any target not requiring UART involvement doesn't (and probably, shouldn't) be expressed as a slave device. IMHO it is not obligatory to represent the direction of control by a parentchild relation in DT. DT just needs to describe that there is a relation/connection. The driver code already must “know” the direction of notifications. BTW, there can even be control in reverse direction in some cases. E.g. the slave driver wants to automatically set the baud rate of the uart, i.e. the slave controls the uart on /dev/tty side. If I have monitored some other discussion right, this is exactly done by a Codec driver to tell its mcbsp counterpart about clock rates and data formats it should expect. Maybe this is the reason why McBSP use (or are just happy with) the phandle approach. BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Peter, Am 07.05.2015 um 17:51 schrieb Peter Hurley pe...@hurleysoftware.com: On 05/07/2015 11:34 AM, Dr. H. Nikolaus Schaller wrote: Am 07.05.2015 um 16:56 schrieb Peter Hurley pe...@hurleysoftware.com: On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote: Both devicetree and tty/serial can already represent independent control; what is proposed is a way to express dependent control, and in all cases, that control stems directly from either the UART state itself or via commands sent over that interface. Yes. This is why I propose that the tty/uart driver can send an internal notification to the device driver. And the device driver can register to be notified by the UART that is identified by the phandle of the slave DT entry. I've not seen any code with your proposal, so that makes it impossible to compare competing solutions. If you can give me some (unspecified) time to do it, I can write (simplified) patches to demonstrate the idea. I just hesitate to work out and submit a counter proposal to what Neil has submitted, because it will become wasted effort if it is rejected before I am finished. Any target not requiring UART involvement doesn't (and probably, shouldn't) be expressed as a slave device. IMHO it is not obligatory to represent the direction of control by a parentchild relation in DT. DT just needs to describe that there is a relation/connection. Devicetree usage in the linux kernel is for representing the host view, not an abstract machine. I have yet to see an example of a proposed tty slave where the host interface is not a UART. So far, I am only aware of two devices proposed to be tty power controlled slaves: * our GPS chip and * several Bluetooth modules (using HCI). It is difficult to predict future use cases and systems. With some phantasy there could be some I2C controlled serial level shifter that translates uart RX/TX/RTS/CTS to RS232 levels but allows for pin swapping (null modem). Power control of that chip is done through I2C. Similar chips exist for headset pinout detection ans automatic swapping, e.g. TS3A225E. Or some Infrared (IrDA) transceiver with mode and power control over I2C. Such a device should probably be described as a child node of the I2C bus it is connected to. And the driver must become an i2c device driver. So this would be in conflict with tty slave child nodes - but no problem with a phandle to the uart. The driver code already must “know” the direction of notifications. BTW, there can even be control in reverse direction in some cases. E.g. the slave driver wants to automatically set the baud rate of the uart, i.e. the slave controls the uart on /dev/tty side. If I have monitored some other discussion right, this is exactly done by a Codec driver to tell its mcbsp counterpart about clock rates and data formats it should expect. Maybe this is the reason why McBSP use (or are just happy with) the phandle approach. Parameters are not control. Agreed. Especially if you mean power control. But does it change the necessity to describe the control direction in the DT as parentchild? In many other situations power control is described by regulator phandles and the regulators are not children of the controlling DT node. BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi,
Am 07.05.2015 um 18:18 schrieb Peter Hurley pe...@hurleysoftware.com:
On 05/07/2015 11:11 AM, Dr. H. Nikolaus Schaller wrote:
Am 07.05.2015 um 16:30 schrieb Peter Hurley pe...@hurleysoftware.com:
On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
Am 06.05.2015 um 19:18 schrieb Mark Rutland mark.rutl...@arm.com:
On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
Am 06.05.2015 um 16:15 schrieb Mark Rutland mark.rutl...@arm.com:
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.
[...]
If this happens, you can move the slave device into a fragment that
you
can include under the correct node. That's trivial.
But less readable. And that is important as well.
I disagree. The manipulation you have to perform to override properties
is at least as bad as including a file.
What about:
#include omap3-beagle-xm.dts
/ {
/* HS USB Port 2 Power enable was inverted with the xM C */
hsusb2_power: hsusb2_power_reg {
enable-active-high;
};
};
compared to
#include “board1.dts”
/ {
/* slave was reconnected to uart4 */
slave {
uart = uart4;
};
};
As I mentioned, you can easily carve up your DTS to make that work with
includes if you really must:
/* UART0 board variant */
#include board.dtsi
uart0 {
#include some-uart-slave.dtsi
};
/* UART1 board variant */
#include board.dtsi
uart1 {
#include some-uart-slave.dtsi
};
If you happen to find includes ugly then you can say it's ugly, but it's
functionally equivalent, and also means you can avoid having
disabled/partial nodes all over the place.
Functionally equivalent would also be to copy the whole source file and
s/uart0/uart1/.
But this is not the best solution for the DT programmer since there is no
automatic *reuse* of common parts.
And your proposal requires 3 source files instead of 2 which deteriorates
readibility and understanding what is really going on. And if you need to
change the some-uart-slave, you have to touch a different file than for
changing some other slave.
Yes, it works, but IMHO other factors for a good design are also important.
Maybe our main difference in PoV is that I specifically want to avoid that
we force future DT programmers into “ugly” solutions (even if they work).
If you think that DT programmers have to live with what they are
given and do the best with it, we can end the discussion.
The question of syntax is orthogonal to the discussion of the proper
devicetree representation.
The awkwardness of expressing variants has nothing to do with the
appropriate device hierarchy (or whether there should be a hierarchy).
Describing variants is just as awkward when the parent-child relationship
is indisputable.
That is ok. But I still have not found the key rule when a parent-child
relationship
is indisputable. Candidates so far are “main interface” (which is still
disputable)
or “bus” (where we can dispute if a point-to-point connection is a “bus”).
Actually, at this point there is only one candidate, and that is the code
under review.
I meant two different candiates for DT bindings [PATCH 3/3]. Yes, the code
exists only for Neil’s proposal.
But if both options are equally valid (maybe because there is no rule
making either indisputable), I would chose the one with easier syntax.
There are many important criteria here.
1. Code complexity
2. Ease of adoption
3. Quality of abstraction
4. Extensibility
Yes. That is why I insist on discussing alternatives to show how good they
are wrt to such criteria and so far the discussion wasn’t that well structured
to have clear criteria in the beginning. Thanks.
There was a recent discussion on devicetree ML regarding how best to
express and represent variance. Feel free to revive that discussion.
Does it help? Our core issue is not the syntax and variance per se. This are
just examples to demonstrate differences in syntax of parent-child vs.
phandle.
If we decide for either one, we have to live with syntactical and other
implcationd.
The future implications of both the design and implementation need
careful consideration. That's why I'd like to see a v4.
Yes, I appreciate that!
And if I find time, I will propose a v4-alternative.
BR and thanks,
Nikolaus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Pavel, Am 06.05.2015 um 16:28 schrieb Pavel Machek : > On Wed 2015-05-06 13:50:29, Dr. H. Nikolaus Schaller wrote: >> 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. > > Ok, so now device tree maintainers spoke and told you, you are wrong, did they already say that and have more convincing arguments? So far I have always identified a flaw in the argumentation or a contradiction with practice (e.g. busses are usually addressable, McBSP and PHY do uses phandle and not subnodes). > and you still argue? And as long as I think the others are still wrong (focussed to see and model UART like a “bus”), I tell them and explain my arguments where and why I disagree with what they say or propose. Especially if I feel that their arguments are not technically convincing (me). Although all this is less about technical solutions but design principles: what makes a good DT design. Well, Linux will survive with any solution, but what are you interested in? Users/contributors who keep quiet and accept a bad solution or those who argue for a (initially in their opinion) better one? Or stop as soon as Pavel says to do so? > You'll only attrack more "wonderful" arguments > that way. 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. 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). Then we all can go to implementation. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Mark,
Am 06.05.2015 um 16:15 schrieb Mark Rutland :
>> 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.
>
> [...]
>
>>> If this happens, you can move the slave device into a fragment that you
>>> can include under the correct node. That's trivial.
>>
>> But less readable. And that is important as well.
>
> I disagree. The manipulation you have to perform to override properties
> is at least as bad as including a file.
What about:
#include "omap3-beagle-xm.dts"
/ {
/* HS USB Port 2 Power enable was inverted with the xM C */
hsusb2_power: hsusb2_power_reg {
enable-active-high;
};
};
compared to
#include “board1.dts”
/ {
/* slave was reconnected to uart4 */
slave {
uart = <>;
};
};
>
So the main difference is if the slave device tells to which uart it is
connected
or the uart which slave device it is connected to.
And I think the second approach is easier and more straightforward (on DT
level).
>>>
>>> We already place child nodes under their respective busses
>>
>> I still wonder why UART is considered as a bus?
>
> As Neil mentioned earlier, ignore "bus". Here we're caring about a 1-1
> connection between master (UART) and slave (device), and it happens that
> in most other cases the master is actually a bus, so that's how things
> happen to be named.
So you also mean that all master-slave connections must be represented
by DT subnodes and everything else is not acceptable?
What about:
sound {
compatible = "ti,omap-twl4030";
ti,model = "omap3beagle";
ti,mcbsp = <>;
};
Isn’t McBSP a “bus” with your definition as well? Like a “master”. And the
“twl4030”
is the slave (codec)?
_otg_hs {
interface-type = <0>;
usb-phy = <_phy>;
phys = <_phy>;
phy-names = "usb2-phy";
mode = <3>;
power = <50>;
};
Isn’t a PHY interface (e.g. ULPI-PHY) a “slave” connected to a 12 wire ULPI
“bus” as well?
At least in this two areas everything done so far appears to contradict your
argument.
This is for me the blueprint how it should be done for UART slaves like any
point-to-point
multi-wire interfaces (question not even discussed: does UART-to-UART have
clear master
and slave roles? Isn’t the connected device the “master”? but I don’t want to
broaden the
discussion again).
This is basically why I keep this discussion open, because it is not that
obvious
that Neil’s proposal is right and mine is wrong.
>
>>> for other
>>> interfaces like SPI and I2C. I do not see a compelling reason to do
>>> otherwise for devices
>>
>> why the plural? Is there a practical example where multiple devices are
>> connected to a single UART and how is addressing solved?
>
> I'm talking about UART slaves in abstract rather than multiple slaves
> attached to the same UART.
Ok, I did misunderstand. Thanks.
>
>>> hanging off of UARTs -- doing so would make things
>>> less straightforward because you have a fundamentally different idiom.
>>
>> Yes, my proposal is fundamentally different from I2C and SPI practice, but
>> it is the same that is heavily used for e.g. GPIOs and Regulators.
>
> Well, those cases are somewhat distinct, and I'd say that UART slaves
> are much closer to SPI/I2C devices than GPIOs or regulators.
As shown above they are IMHO closer to McBSP and ULPI-PHY (and some
other interfaces).
>
> Let's say I have a GPIO described via a phandle. That GPIO is actually
> owned by some GPIO controller whose control interface is sat on an MMIO
> bus. What we're describing with the phandle is use of the GPIO, but not
> the main interface for interactive with the GPIO, which is the MMIO
> interface of the controller.
Right. For the UART we do the same: the UART controller is connected
to the MMIO and (in my proposal) the phandle describes the use of the UART
(to connect to some slave device). Exactly the same situation.
>
> In the case of UART slave devices the control interface is attached to
> the UART, and effectively the slave sits on the UART's "bus". We could
> refer to it from elsewhere by phandle, but its canonical parent should
> be the UART, as that’s what its main interface is attached to.
What is the “main interface” of some device? Why should it have a special
role in DT? I have doubts that it is useful to declare some interface as “main”,
unless it is a MMIO bus connection.
There are e.g. chips with multi-interfaces like a twl4030. They have 2 I2C
busses, 2 PCM
“busses”, an ULIP-PHY and some GPIOs. Or some 3G/4G modems which have
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Mark,
Am 06.05.2015 um 14:36 schrieb Mark Rutland :
> On Wed, May 06, 2015 at 01:27:03PM +0100, Dr. H. Nikolaus Schaller wrote:
>> Hi Peter,
>>
>> Am 06.05.2015 um 14:05 schrieb Peter Hurley :
>>
>>> On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:
>>>> 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.
>>>
>>> I dont' see a big distinction at the DTS source level, so your concern is
>>> wrt
>>> binary dtbs?
>>
>> No. My concern is wrt including existing board files and making small
>> modifications
>> on source level (or overlays).
>>
>> We discuss:
>>
>> board1.dts:
>>
>> uart3 { // subnode of some SoC
>> slave { // slave connected to uart3
>> compatible = „…“;
>> gpio = < 12 0>
>> };
>> };
>>
>> vs.
>>
>> board1.dts:
>>
>> / {
>> slave {
>> compatible = „…“;
>> gpio = < 12 0>
>> uart = // slave connected to uart3
>> };
>> };
>>
>> uart3 { // subnode of some SoC
>> };
>>
>> now let’s have a spin of the board design which just rewires the
>> slave to uart4 (somtimes hardware engineers do such things).
>>
>> board2.dts:
>>
>> #include
>>
>> // reconnect device to uart4
>>
>> uart4 { // subnode of some SoC
>> slave { // slave connected to uart4
>> compatible = „…“;
>> gpio = < 12 0>
>> };
>> };
>>
>> uart3 { // subnode of some SoC
>> slave { // slave connected to uart3
>> compatible = „none“ // we can’t delete imported
>> subnodes
>> };
>> };
>>
>> /// add another device to uart5?
>>
>> uart5 { // subnode of some SoC
>> slave2 {// slave connected to uart5
>> compatible = „…“;
>> gpio = < 13 0>
>> };
>> };
>
> If this happens, you can move the slave device into a fragment that you
> can include under the correct node. That's trivial.
But less readable. And that is important as well.
>
> If you have a large amount of variation within a given platform, that is
> a problem with your platform.
Agreed.
>
>> So the main difference is if the slave device tells to which uart it is
>> connected
>> or the uart which slave device it is connected to.
>>
>> And I think the second approach is easier and more straightforward (on DT
>> level).
>
> We already place child nodes under their respective busses
I still wonder why UART is considered as a bus?
For me it is a point-to-point interface, and not a bus.
I assume that a majority of engineers outside of our discussion tend to agree.
[random pick: http://www.avrfreaks.net/comment/473738#comment-473738
"So basically, UART is not a bus. If you really want to connect N devices
together,
use I2C maybe, it too has two wires and anyone can be master.“]
Even some ISO standards define a „bus“ as something with addressable clients
(and UART has no addresses since it has no protocol by itself).
> for other
> interfaces like SPI and I2C. I do not see a compelling reason to do
> otherwise for devices
why the plural? Is there a practical example where multiple devices are
connected to a single UART and how is addressing solved?
> hanging off of UARTs -- doing so would make things
> less straightforward because you have a fundamentally different idiom.
Yes, my proposal is fundamentally different from I2C and SPI practice, but
it is the same that is heavily used for e.g. GPIOs and Regulators.
So it is not at all a „different“ idiom. Just one that IMHO better fits for
point-to-point connections (like power distribution or GPIOs). Therefore
I have a reason to use a different idiom for a technically different
task.
>
> Having the slave live under the UART node also gives you sane probe
> ordering -- you must probe the parent before the slave as the parent
> driver (perhaps via common code) will trigger the scan of children.
This is a good and interesting argument in favour of the subnodes approach.
I know there was (is?) a problem wi
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Peter,
Am 06.05.2015 um 14:05 schrieb Peter Hurley :
> On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:
>> 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.
>
> I dont' see a big distinction at the DTS source level, so your concern is wrt
> binary dtbs?
No. My concern is wrt including existing board files and making small
modifications
on source level (or overlays).
We discuss:
board1.dts:
uart3 { // subnode of some SoC
slave { // slave connected to uart3
compatible = „…“;
gpio = < 12 0>
};
};
vs.
board1.dts:
/ {
slave {
compatible = „…“;
gpio = < 12 0>
uart = // slave connected to uart3
};
};
uart3 { // subnode of some SoC
};
now let’s have a spin of the board design which just rewires the
slave to uart4 (somtimes hardware engineers do such things).
board2.dts:
#include
// reconnect device to uart4
uart4 { // subnode of some SoC
slave { // slave connected to uart4
compatible = „…“;
gpio = < 12 0>
};
};
uart3 { // subnode of some SoC
slave { // slave connected to uart3
compatible = „none“ // we can’t delete imported
subnodes
};
};
/// add another device to uart5?
uart5 { // subnode of some SoC
slave2 {// slave connected to uart5
compatible = „…“;
gpio = < 13 0>
};
};
vs.
board2.dts:
#include
// reconnect device to uart4
{
uart =
};
// add another device to uart5?
slave2 {
compatible = „…“;
gpio = < 13 0>
uart =
};
So the main difference is if the slave device tells to which uart it is
connected
or the uart which slave device it is connected to.
And I think the second approach is easier and more straightforward (on DT
level).
>
>> 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.
>
> I would expect _no_ impact on the tty driver; have I overlooked something?
The way a tty driver finds the slave or the slave finds the tty driver instance.
In my proposal, the slave device has to look up the uart instance it is
connected
to and must register itself as a power management client to get notifications.
It
can also receive other notifications or change the line discipline to its needs.
In Neil’s original proposal the tty driver simply imposes some special power
management methods (control gpio or a regulator) over the slave driver which
does not encapsulate it’s power management methods.
BR,
Nikolaus--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Peter,
Am 06.05.2015 um 14:05 schrieb Peter Hurley pe...@hurleysoftware.com:
On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:
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.
I dont' see a big distinction at the DTS source level, so your concern is wrt
binary dtbs?
No. My concern is wrt including existing board files and making small
modifications
on source level (or overlays).
We discuss:
board1.dts:
uart3 { // subnode of some SoC
slave { // slave connected to uart3
compatible = „…“;
gpio = gpio5 12 0
};
};
vs.
board1.dts:
/ {
slave {
compatible = „…“;
gpio = gpio5 12 0
uart = uart3; // slave connected to uart3
};
};
uart3 { // subnode of some SoC
};
now let’s have a spin of the board design which just rewires the
slave to uart4 (somtimes hardware engineers do such things).
board2.dts:
#include board-variant1.dts
// reconnect device to uart4
uart4 { // subnode of some SoC
slave { // slave connected to uart4
compatible = „…“;
gpio = gpio5 12 0
};
};
uart3 { // subnode of some SoC
slave { // slave connected to uart3
compatible = „none“ // we can’t delete imported
subnodes
};
};
/// add another device to uart5?
uart5 { // subnode of some SoC
slave2 {// slave connected to uart5
compatible = „…“;
gpio = gpio5 13 0
};
};
vs.
board2.dts:
#include board-variant1.dts
// reconnect device to uart4
slave {
uart = uart3;
};
// add another device to uart5?
slave2 {
compatible = „…“;
gpio = gpio5 13 0
uart = uart5;
};
So the main difference is if the slave device tells to which uart it is
connected
or the uart which slave device it is connected to.
And I think the second approach is easier and more straightforward (on DT
level).
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.
I would expect _no_ impact on the tty driver; have I overlooked something?
The way a tty driver finds the slave or the slave finds the tty driver instance.
In my proposal, the slave device has to look up the uart instance it is
connected
to and must register itself as a power management client to get notifications.
It
can also receive other notifications or change the line discipline to its needs.
In Neil’s original proposal the tty driver simply imposes some special power
management methods (control gpio or a regulator) over the slave driver which
does not encapsulate it’s power management methods.
BR,
Nikolaus--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Mark,
Am 06.05.2015 um 14:36 schrieb Mark Rutland mark.rutl...@arm.com:
On Wed, May 06, 2015 at 01:27:03PM +0100, Dr. H. Nikolaus Schaller wrote:
Hi Peter,
Am 06.05.2015 um 14:05 schrieb Peter Hurley pe...@hurleysoftware.com:
On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:
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.
I dont' see a big distinction at the DTS source level, so your concern is
wrt
binary dtbs?
No. My concern is wrt including existing board files and making small
modifications
on source level (or overlays).
We discuss:
board1.dts:
uart3 { // subnode of some SoC
slave { // slave connected to uart3
compatible = „…“;
gpio = gpio5 12 0
};
};
vs.
board1.dts:
/ {
slave {
compatible = „…“;
gpio = gpio5 12 0
uart = uart3; // slave connected to uart3
};
};
uart3 { // subnode of some SoC
};
now let’s have a spin of the board design which just rewires the
slave to uart4 (somtimes hardware engineers do such things).
board2.dts:
#include board-variant1.dts
// reconnect device to uart4
uart4 { // subnode of some SoC
slave { // slave connected to uart4
compatible = „…“;
gpio = gpio5 12 0
};
};
uart3 { // subnode of some SoC
slave { // slave connected to uart3
compatible = „none“ // we can’t delete imported
subnodes
};
};
/// add another device to uart5?
uart5 { // subnode of some SoC
slave2 {// slave connected to uart5
compatible = „…“;
gpio = gpio5 13 0
};
};
If this happens, you can move the slave device into a fragment that you
can include under the correct node. That's trivial.
But less readable. And that is important as well.
If you have a large amount of variation within a given platform, that is
a problem with your platform.
Agreed.
So the main difference is if the slave device tells to which uart it is
connected
or the uart which slave device it is connected to.
And I think the second approach is easier and more straightforward (on DT
level).
We already place child nodes under their respective busses
I still wonder why UART is considered as a bus?
For me it is a point-to-point interface, and not a bus.
I assume that a majority of engineers outside of our discussion tend to agree.
[random pick: http://www.avrfreaks.net/comment/473738#comment-473738
So basically, UART is not a bus. If you really want to connect N devices
together,
use I2C maybe, it too has two wires and anyone can be master.“]
Even some ISO standards define a „bus“ as something with addressable clients
(and UART has no addresses since it has no protocol by itself).
for other
interfaces like SPI and I2C. I do not see a compelling reason to do
otherwise for devices
why the plural? Is there a practical example where multiple devices are
connected to a single UART and how is addressing solved?
hanging off of UARTs -- doing so would make things
less straightforward because you have a fundamentally different idiom.
Yes, my proposal is fundamentally different from I2C and SPI practice, but
it is the same that is heavily used for e.g. GPIOs and Regulators.
So it is not at all a „different“ idiom. Just one that IMHO better fits for
point-to-point connections (like power distribution or GPIOs). Therefore
I have a reason to use a different idiom for a technically different
task.
Having the slave live under the UART node also gives you sane probe
ordering -- you must probe the parent before the slave as the parent
driver (perhaps via common code) will trigger the scan of children.
This is a good and interesting argument in favour of the subnodes approach.
I know there was (is?) a problem with GPIO controllers not probed before
they are referenced. That made some problems for OMAP around release
3.14. But AFAIK it is solved now (don’t know the details how it is solved).
Anyways, I wonder why probing and probe order should be implicitly reflected
by the DT? If DT is really a hardware description (and not a tool for kernel
code
optimisation), then it should not matter and other aspects should have a higher
priority. E.g. which information is to be provided by the slave node and which
by the uart node.
The key point appears to be how we want to see the serial connection. Is the
device connected to the uart or the uart to a device?
In OO terminology: „device connects to uart“ vs. „uart has device connected“.
d - u“ vs. u - d“.
For a bus like I2C or SPI it is „controller has device
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Pavel, Am 06.05.2015 um 11:27 schrieb Pavel Machek pa...@ucw.cz: 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 pe...@hurleysoftware.com: 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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Mark,
Am 06.05.2015 um 16:15 schrieb Mark Rutland mark.rutl...@arm.com:
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.
[...]
If this happens, you can move the slave device into a fragment that you
can include under the correct node. That's trivial.
But less readable. And that is important as well.
I disagree. The manipulation you have to perform to override properties
is at least as bad as including a file.
What about:
#include omap3-beagle-xm.dts
/ {
/* HS USB Port 2 Power enable was inverted with the xM C */
hsusb2_power: hsusb2_power_reg {
enable-active-high;
};
};
compared to
#include “board1.dts”
/ {
/* slave was reconnected to uart4 */
slave {
uart = uart4;
};
};
So the main difference is if the slave device tells to which uart it is
connected
or the uart which slave device it is connected to.
And I think the second approach is easier and more straightforward (on DT
level).
We already place child nodes under their respective busses
I still wonder why UART is considered as a bus?
As Neil mentioned earlier, ignore bus. Here we're caring about a 1-1
connection between master (UART) and slave (device), and it happens that
in most other cases the master is actually a bus, so that's how things
happen to be named.
So you also mean that all master-slave connections must be represented
by DT subnodes and everything else is not acceptable?
What about:
sound {
compatible = ti,omap-twl4030;
ti,model = omap3beagle;
ti,mcbsp = mcbsp2;
};
Isn’t McBSP a “bus” with your definition as well? Like a “master”. And the
“twl4030”
is the slave (codec)?
usb_otg_hs {
interface-type = 0;
usb-phy = usb2_phy;
phys = usb2_phy;
phy-names = usb2-phy;
mode = 3;
power = 50;
};
Isn’t a PHY interface (e.g. ULPI-PHY) a “slave” connected to a 12 wire ULPI
“bus” as well?
At least in this two areas everything done so far appears to contradict your
argument.
This is for me the blueprint how it should be done for UART slaves like any
point-to-point
multi-wire interfaces (question not even discussed: does UART-to-UART have
clear master
and slave roles? Isn’t the connected device the “master”? but I don’t want to
broaden the
discussion again).
This is basically why I keep this discussion open, because it is not that
obvious
that Neil’s proposal is right and mine is wrong.
for other
interfaces like SPI and I2C. I do not see a compelling reason to do
otherwise for devices
why the plural? Is there a practical example where multiple devices are
connected to a single UART and how is addressing solved?
I'm talking about UART slaves in abstract rather than multiple slaves
attached to the same UART.
Ok, I did misunderstand. Thanks.
hanging off of UARTs -- doing so would make things
less straightforward because you have a fundamentally different idiom.
Yes, my proposal is fundamentally different from I2C and SPI practice, but
it is the same that is heavily used for e.g. GPIOs and Regulators.
Well, those cases are somewhat distinct, and I'd say that UART slaves
are much closer to SPI/I2C devices than GPIOs or regulators.
As shown above they are IMHO closer to McBSP and ULPI-PHY (and some
other interfaces).
Let's say I have a GPIO described via a phandle. That GPIO is actually
owned by some GPIO controller whose control interface is sat on an MMIO
bus. What we're describing with the phandle is use of the GPIO, but not
the main interface for interactive with the GPIO, which is the MMIO
interface of the controller.
Right. For the UART we do the same: the UART controller is connected
to the MMIO and (in my proposal) the phandle describes the use of the UART
(to connect to some slave device). Exactly the same situation.
In the case of UART slave devices the control interface is attached to
the UART, and effectively the slave sits on the UART's bus. We could
refer to it from elsewhere by phandle, but its canonical parent should
be the UART, as that’s what its main interface is attached to.
What is the “main interface” of some device? Why should it have a special
role in DT? I have doubts that it is useful to declare some interface as “main”,
unless it is a MMIO bus connection.
There are e.g. chips with multi-interfaces like a twl4030. They have 2 I2C
busses, 2 PCM
“busses”, an ULIP-PHY and some GPIOs. Or some 3G/4G modems which have
USB, UART (both useable for AT commands in parallel!), PCM and some GPIOs.
Which interface is “main”? For the twl4030 it happens that one of
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Pavel, Am 06.05.2015 um 16:28 schrieb Pavel Machek pa...@ucw.cz: On Wed 2015-05-06 13:50:29, Dr. H. Nikolaus Schaller wrote: Hi Pavel, Am 06.05.2015 um 11:27 schrieb Pavel Machek pa...@ucw.cz: 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 pe...@hurleysoftware.com: 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. Ok, so now device tree maintainers spoke and told you, you are wrong, did they already say that and have more convincing arguments? So far I have always identified a flaw in the argumentation or a contradiction with practice (e.g. busses are usually addressable, McBSP and PHY do uses phandle and not subnodes). and you still argue? And as long as I think the others are still wrong (focussed to see and model UART like a “bus”), I tell them and explain my arguments where and why I disagree with what they say or propose. Especially if I feel that their arguments are not technically convincing (me). Although all this is less about technical solutions but design principles: what makes a good DT design. Well, Linux will survive with any solution, but what are you interested in? Users/contributors who keep quiet and accept a bad solution or those who argue for a (initially in their opinion) better one? Or stop as soon as Pavel says to do so? You'll only attrack more wonderful arguments that way. 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. 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). Then we all can go to implementation. BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
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. BR, Nikolaus (1) best with respect to maintainability, flexibility, common design patterns, compatibility and some other factors I don’t know the correct english words for (2) basically the slave can be described as a subnode like for I2C bus slaves or the slave device can reference the uart it is connected to like for GPIOs and regulators-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.
Hi Peter, Am 05.05.2015 um 21:54 schrieb Peter Hurley pe...@hurleysoftware.com: 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. BR, Nikolaus (1) best with respect to maintainability, flexibility, common design patterns, compatibility and some other factors I don’t know the correct english words for (2) basically the slave can be described as a subnode like for I2C bus slaves or the slave device can reference the uart it is connected to like for GPIOs and regulators-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi Pavel, Am 27.04.2015 um 22:35 schrieb Pavel Machek : > Hi! > >>> In my opinion making something a node in / is always the >>> last resort and in my perspective it has been handled in such a way >>> so far. >> >> But that contradicts some documents I have found and linked. Please >> show me a document about DT that supports your view. >> >> I agree that both views can be valid, but in lack of some ?official? >> guideline >> we can?t decide ourselves. > > This is not how kernel development works. > > We can decide ourselves, and DT people will swear at us if we decide wrongly, > and then Linus swears at them if they do too obvious mistakes. > > Lets KISS. some time ago you also wrote in this thread: > Device tree is not operating system specific. In other words: this is a discussion about compatibility with the world outside of Linux. And compatibility can not be achieved by decisions about Linux implementation details, even if Linus is deciding. He can just decide to stay incompatible (but then it should IMHO be a general decision and not case specific). So I think we should follow some basic design principles, if they exist (which I don’t know), to have this compatibility. And then adapt the Linux implementation (using the KISS principle). Anyways I have not yet seen any comment from the DT people or did I miss them? BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi Pavel, Am 27.04.2015 um 22:35 schrieb Pavel Machek pa...@ucw.cz: Hi! In my opinion making something a node in / is always the last resort and in my perspective it has been handled in such a way so far. But that contradicts some documents I have found and linked. Please show me a document about DT that supports your view. I agree that both views can be valid, but in lack of some ?official? guideline we can?t decide ourselves. This is not how kernel development works. We can decide ourselves, and DT people will swear at us if we decide wrongly, and then Linus swears at them if they do too obvious mistakes. Lets KISS. some time ago you also wrote in this thread: Device tree is not operating system specific. In other words: this is a discussion about compatibility with the world outside of Linux. And compatibility can not be achieved by decisions about Linux implementation details, even if Linus is deciding. He can just decide to stay incompatible (but then it should IMHO be a general decision and not case specific). So I think we should follow some basic design principles, if they exist (which I don’t know), to have this compatibility. And then adapt the Linux implementation (using the KISS principle). Anyways I have not yet seen any comment from the DT people or did I miss them? BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi Pavel, Am 04.04.2015 um 10:16 schrieb Pavel Machek : > Hi! > Please propose your own code doing that so that we can test if it is better. >>> >>> So, how does this look? >>> >>> It looks to me like you have cca 0.1 Ohm resistance in your system, >> >> This is completely unknown. >> >>> and are using cca 75mA while discharging, and charge by cca 1.4A. >> >> Where do you get these figures from? > > Least squares fitting of my coefficients to your tables. Ah, I see. > >> A GTA04 board discharges usually between 50 and 400 mA (depending on >> activities) >> and if you turn on WiFi, it will be up to 600 mA. If you use 3G it can draw >> even more >> during operation. > > How big battery do you have? 1200 mAh > According to least squares fitting, > assuming maximum charge of .46A, you were taking about 25mA when > doing the discharge test. No, that can’t fit well. But I do not remember who has done this calibration in which situation because it was done many months ago for the platform data version. We have just reformatted the table for the DT. > >> Total current going in is 500-800 mA (depending on USB negotiations) and >> this is >> split into system operation and charging current. So 1.4A charging current >> is not >> possible. Rather 200-500 mA. >> >> So it might be that the battery is discharged although the system is >> connected >> to a charger. > > Yah, and your battery meter will be wrong in such case, as will be > mine, because they are based on same information. Well, it is not “mine”, it is the platform_data based driver already in kernel.org since ca. 3.12. We have just updated it to DT to get rid of platform_data in this area as well… Yes, I see your argument that hiding the tables (two characteristic curves) into an analytic approximation can be superior. The problem I see is just that your formula needs some parameters which are difficult to derive or estimate. And must be adjusted to the specific battery and system setup in a non-trivial way. At least we must supply a tool (in the kernel/scripts directory?) where someone can can estimate the parameters of the formula from the characteristic curves. Maybe a tool that automatically runs several charge/discharge cycles at different system load. And measures time vs. voltage. And assumes a linear capacity decrease between the end points. (i.e. if it needs 10 hours to charge from completely empty to full, we can assume 50% after 5,0 hours). So my goal is to measure all characteristics of the battery - and no need to study a (potentially non-existing) data sheet. If you can provide that for all parameters of your algorithm I am fine with it. > The thing is, mine > can be improved without adding more tables. How can you improve your algorithm without tweaking or adding new parameters? > >>> It is tricky to do a good job near 0%... or anywhere else. See for >>> example >>> >>> http://cseweb.ucsd.edu/~trosing/lectures/battery.pdf >>> >>> You start a call, percentage goes down, end a call, it will go >>> back up. I'm pretty sure you will not be able to make a call with "5%" >>> indication from your code at low battery temperature (say -10C). >> >> The whole system is heating up a little, so that you never have -10C for the >> battery. > > Umm. When not calling, your phone should not heat itself up. Yes, in suspend it needs <20 mA which does not heat or course. But steady operation at 20-400 mA does significantly rise OMAP temperature beyond environment temperature. > And you > definitely can power it down, leave it in outer pocket, then power it > up. It is actually something people do when they want to preserve battery... > >> I think you are trying to solve situations that don’t exist in practice. >> >> And AFAIK, the GTA04 board is the only user of this driver in case the >> battery >> has no built-in fuel gauge. So why improve it beyond what the GTA04 >> users need? > > Because then other users can share the same code, and because you But you have ugly parameters in dts that nobody can easily see in the schematics and that are full of assumptions. >From a perspective of uncertainty analysis, estimation of the internal >parameters needs a higher precision than the calibration points. > avoid big ugly tables in dts. Well, the biggest tables I have seen in dts are keyboard matrix codes… > >> I repeat myself: this driver is not built for highest precision because >> there are >> better methods (fuel gauge chip). These might not be available so this >> fall-back >> driver has been built. >> >> It is definitively better than no driver and worse than the optimum. > > And my email suggested solution better than your driver, so why not > just use it? I am not yet convinced that it is better. It just moves the (unavoidable) limitations (measuring multiple calibration points) just to a different area (measuring the hidden and not precisely known parameter of the system). > > >>>
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi Pavel, Am 04.04.2015 um 10:16 schrieb Pavel Machek pa...@ucw.cz: Hi! Please propose your own code doing that so that we can test if it is better. So, how does this look? It looks to me like you have cca 0.1 Ohm resistance in your system, This is completely unknown. and are using cca 75mA while discharging, and charge by cca 1.4A. Where do you get these figures from? Least squares fitting of my coefficients to your tables. Ah, I see. A GTA04 board discharges usually between 50 and 400 mA (depending on activities) and if you turn on WiFi, it will be up to 600 mA. If you use 3G it can draw even more during operation. How big battery do you have? 1200 mAh According to least squares fitting, assuming maximum charge of .46A, you were taking about 25mA when doing the discharge test. No, that can’t fit well. But I do not remember who has done this calibration in which situation because it was done many months ago for the platform data version. We have just reformatted the table for the DT. Total current going in is 500-800 mA (depending on USB negotiations) and this is split into system operation and charging current. So 1.4A charging current is not possible. Rather 200-500 mA. So it might be that the battery is discharged although the system is connected to a charger. Yah, and your battery meter will be wrong in such case, as will be mine, because they are based on same information. Well, it is not “mine”, it is the platform_data based driver already in kernel.org since ca. 3.12. We have just updated it to DT to get rid of platform_data in this area as well… Yes, I see your argument that hiding the tables (two characteristic curves) into an analytic approximation can be superior. The problem I see is just that your formula needs some parameters which are difficult to derive or estimate. And must be adjusted to the specific battery and system setup in a non-trivial way. At least we must supply a tool (in the kernel/scripts directory?) where someone can can estimate the parameters of the formula from the characteristic curves. Maybe a tool that automatically runs several charge/discharge cycles at different system load. And measures time vs. voltage. And assumes a linear capacity decrease between the end points. (i.e. if it needs 10 hours to charge from completely empty to full, we can assume 50% after 5,0 hours). So my goal is to measure all characteristics of the battery - and no need to study a (potentially non-existing) data sheet. If you can provide that for all parameters of your algorithm I am fine with it. The thing is, mine can be improved without adding more tables. How can you improve your algorithm without tweaking or adding new parameters? It is tricky to do a good job near 0%... or anywhere else. See for example http://cseweb.ucsd.edu/~trosing/lectures/battery.pdf You start a call, percentage goes down, end a call, it will go back up. I'm pretty sure you will not be able to make a call with 5% indication from your code at low battery temperature (say -10C). The whole system is heating up a little, so that you never have -10C for the battery. Umm. When not calling, your phone should not heat itself up. Yes, in suspend it needs 20 mA which does not heat or course. But steady operation at 20-400 mA does significantly rise OMAP temperature beyond environment temperature. And you definitely can power it down, leave it in outer pocket, then power it up. It is actually something people do when they want to preserve battery... I think you are trying to solve situations that don’t exist in practice. And AFAIK, the GTA04 board is the only user of this driver in case the battery has no built-in fuel gauge. So why improve it beyond what the GTA04 users need? Because then other users can share the same code, and because you But you have ugly parameters in dts that nobody can easily see in the schematics and that are full of assumptions. From a perspective of uncertainty analysis, estimation of the internal parameters needs a higher precision than the calibration points. avoid big ugly tables in dts. Well, the biggest tables I have seen in dts are keyboard matrix codes… I repeat myself: this driver is not built for highest precision because there are better methods (fuel gauge chip). These might not be available so this fall-back driver has been built. It is definitively better than no driver and worse than the optimum. And my email suggested solution better than your driver, so why not just use it? I am not yet convinced that it is better. It just moves the (unavoidable) limitations (measuring multiple calibration points) just to a different area (measuring the hidden and not precisely known parameter of the system). #perc = percent(volt) compute(charging, 1) compute(discharging, 0) Please explain what you calculate here. Especially what “Badness” is?
Re: [PATCH] Documentation: usb: serial: fixed how to provide vendor and product id
Hi, Am 30.03.2015 um 12:08 schrieb Johan Hovold : > On Mon, Mar 30, 2015 at 11:32:39AM +0200, Dr. H. Nikolaus Schaller wrote: >> Hi Johan, >> >> Am 30.03.2015 um 09:45 schrieb Johan Hovold : >> >>> On Sat, Mar 28, 2015 at 02:37:57PM +0100, Marek Belisko wrote: >>>> From: "H. Nikolaus Schaller" >>>> >>>> While trying to test the Pyra GSM/GPS/3G module I had reconfigured >>>> the USB interface by mistake and therefore needed to run a different >>>> USB driver than CSC-ACM. It turned out that I need the "usbserial" driver. >>> >>> CDC-ACM >> >> oh, thanks. There is always at least one more typo in any document… >> >>> >>>> This file is an official description how to use it: >>>> Documentation/usb/usb-serial.txt >>>> >>>> But it is outdated. The parameters vendor= and product= are no longer >>>> available since ca. 3.12 which means that documentation is lagging behind >>>> quite some time. >>> >>> This is simply not true. The vendor and module parameters are still >>> there for usbserial (i.e. the generic driver). >>> >>> Would you mind updating this patch to document the sysfs-method as an >>> alternative instead? Using sysfs is preferred as that functionality can >>> be used with any usb-serial driver and the drivers can also be compiled >>> in. >> >> Hm. For me it did not work as described and therefore I searched for >> and found the solution cited below, which appears to confirm that it does >> not work any more. Only with these hints to use the /sys approach I >> could make it working immediately. >> >> Therefore I assumed that the documentation is outdated. >> >> But it might also be a hidden bug with the parameter passing. >> I had tested on 4.0-rc3. >> >> I can try a little more but it might be waste of time to find out why the old >> does not work, if there is a preferred method now. > > Please do try to figure out if it doesn't work as we have not deprecated > this functionality yet. It should still work. Good news: I have tried again (this time with 4.0-rc5) and was successful. I have no clue why it did not work with my tests with 4.0-rc3. Here is the log: > gta04 login: root > Password: > Last login: Thu Apr 2 14:06:13 UTC 2015 on ttyO2 > Linux gta04 4.0.0-rc5-gta04+ #1022 SMP Mon Mar 23 08:13:29 CET 2015 armv7l > > The programs included with the Debian GNU/Linux system are free software; > the exact distribution terms for each program are described in the > individual files in /usr/share/doc/*/copyright. > > Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent > permitted by applicable law. > root@gta04:~# lsusb > Bus 001 Device 002: ID 0424:3503 Standard Microsystems Corp. > Bus 001 Device 003: ID 0424:9730 Standard Microsystems Corp. > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > root@gta04:~# rfkill unblock wwan > [ 40.443892] wwan_on_off_rfkill_set_block: blocked: 0 > [ 40.449109] modem: set_power 0 > [ 40.452318] state 1 > [ 40.454687] modem: send impulse > [ 41.174775] modem: done > root@gta04:~# [ 42.874901] usb 1-2.2: new high-speed USB device number 4 > using ehci-omap > [ 43.008009] usb 1-2.2: New USB device found, idVendor=1e2d, idProduct=0053 > [ 43.015211] usb 1-2.2: New USB device strings: Mfr=3, Product=2, > SerialNumber=0 > [ 43.022859] usb 1-2.2: Product: PH8 > [ 43.026525] usb 1-2.2: Manufacturer: Cinterion > > root@gta04:~# lsusb > Bus 001 Device 002: ID 0424:3503 Standard Microsystems Corp. > Bus 001 Device 003: ID 0424:9730 Standard Microsystems Corp. > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 001 Device 004: ID 1e2d:0053 > root@gta04:~# insmod > /lib/modules/4.0.0-rc5-gta04+/kernel/drivers/usb/serial/usbserial.ko > vendor=0x1e2d product=0x0053 > [ 172.699426] usbcore: registered new interface driver usbserial > [ 172.705714] usbcore: registered new interface driver usbserial_generic > [ 172.715819] usbserial: USB Serial support registered for generic > [ 172.722237] usbserial_generic 1-2.2:1.0: The "generic" usb-serial driver > is only for testing and one-off prototypes. > [ 172.733328] usbserial_generic 1-2.2:1.0: Tell linux-...@vger.kernel.org to > add your device to a proper driver. > [ 172.743848] usbserial_generic 1-2.2:1.0: generic converter detected > [ 172.754681] usb 1-2.2: generic converter now attached to ttyUSB0 > [ 172.761543] usbserial_generic 1-2.2:1.1: The "generic" usb-serial drive
Re: [PATCH] Documentation: usb: serial: fixed how to provide vendor and product id
Am 02.04.2015 um 12:35 schrieb Johan Hovold : > On Thu, Apr 02, 2015 at 12:12:37PM +0200, Jonathan Corbet wrote: >> On Sat, 28 Mar 2015 14:37:57 +0100 >> Marek Belisko wrote: >> >>> This patch changes the documentation file as needed. >> >> Applied to the docs tree (with the changelog typo fixed). > > This patch was incorrect and needed to be updated as discussed in the > thread. Can you drop it or is your tree immutable? Yes, please. I did not find time to test Johan’s valuable comments. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: usb: serial: fixed how to provide vendor and product id
Am 02.04.2015 um 12:35 schrieb Johan Hovold jo...@kernel.org: On Thu, Apr 02, 2015 at 12:12:37PM +0200, Jonathan Corbet wrote: On Sat, 28 Mar 2015 14:37:57 +0100 Marek Belisko ma...@goldelico.com wrote: This patch changes the documentation file as needed. Applied to the docs tree (with the changelog typo fixed). This patch was incorrect and needed to be updated as discussed in the thread. Can you drop it or is your tree immutable? Yes, please. I did not find time to test Johan’s valuable comments. BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: usb: serial: fixed how to provide vendor and product id
Hi, Am 30.03.2015 um 12:08 schrieb Johan Hovold jo...@kernel.org: On Mon, Mar 30, 2015 at 11:32:39AM +0200, Dr. H. Nikolaus Schaller wrote: Hi Johan, Am 30.03.2015 um 09:45 schrieb Johan Hovold jo...@kernel.org: On Sat, Mar 28, 2015 at 02:37:57PM +0100, Marek Belisko wrote: From: H. Nikolaus Schaller h...@goldelico.com While trying to test the Pyra GSM/GPS/3G module I had reconfigured the USB interface by mistake and therefore needed to run a different USB driver than CSC-ACM. It turned out that I need the usbserial driver. CDC-ACM oh, thanks. There is always at least one more typo in any document… This file is an official description how to use it: Documentation/usb/usb-serial.txt But it is outdated. The parameters vendor= and product= are no longer available since ca. 3.12 which means that documentation is lagging behind quite some time. This is simply not true. The vendor and module parameters are still there for usbserial (i.e. the generic driver). Would you mind updating this patch to document the sysfs-method as an alternative instead? Using sysfs is preferred as that functionality can be used with any usb-serial driver and the drivers can also be compiled in. Hm. For me it did not work as described and therefore I searched for and found the solution cited below, which appears to confirm that it does not work any more. Only with these hints to use the /sys approach I could make it working immediately. Therefore I assumed that the documentation is outdated. But it might also be a hidden bug with the parameter passing. I had tested on 4.0-rc3. I can try a little more but it might be waste of time to find out why the old does not work, if there is a preferred method now. Please do try to figure out if it doesn't work as we have not deprecated this functionality yet. It should still work. Good news: I have tried again (this time with 4.0-rc5) and was successful. I have no clue why it did not work with my tests with 4.0-rc3. Here is the log: gta04 login: root Password: Last login: Thu Apr 2 14:06:13 UTC 2015 on ttyO2 Linux gta04 4.0.0-rc5-gta04+ #1022 SMP Mon Mar 23 08:13:29 CET 2015 armv7l The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@gta04:~# lsusb Bus 001 Device 002: ID 0424:3503 Standard Microsystems Corp. Bus 001 Device 003: ID 0424:9730 Standard Microsystems Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@gta04:~# rfkill unblock wwan [ 40.443892] wwan_on_off_rfkill_set_block: blocked: 0 [ 40.449109] modem: set_power 0 [ 40.452318] state 1 [ 40.454687] modem: send impulse [ 41.174775] modem: done root@gta04:~# [ 42.874901] usb 1-2.2: new high-speed USB device number 4 using ehci-omap [ 43.008009] usb 1-2.2: New USB device found, idVendor=1e2d, idProduct=0053 [ 43.015211] usb 1-2.2: New USB device strings: Mfr=3, Product=2, SerialNumber=0 [ 43.022859] usb 1-2.2: Product: PH8 [ 43.026525] usb 1-2.2: Manufacturer: Cinterion root@gta04:~# lsusb Bus 001 Device 002: ID 0424:3503 Standard Microsystems Corp. Bus 001 Device 003: ID 0424:9730 Standard Microsystems Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 004: ID 1e2d:0053 root@gta04:~# insmod /lib/modules/4.0.0-rc5-gta04+/kernel/drivers/usb/serial/usbserial.ko vendor=0x1e2d product=0x0053 [ 172.699426] usbcore: registered new interface driver usbserial [ 172.705714] usbcore: registered new interface driver usbserial_generic [ 172.715819] usbserial: USB Serial support registered for generic [ 172.722237] usbserial_generic 1-2.2:1.0: The generic usb-serial driver is only for testing and one-off prototypes. [ 172.733328] usbserial_generic 1-2.2:1.0: Tell linux-...@vger.kernel.org to add your device to a proper driver. [ 172.743848] usbserial_generic 1-2.2:1.0: generic converter detected [ 172.754681] usb 1-2.2: generic converter now attached to ttyUSB0 [ 172.761543] usbserial_generic 1-2.2:1.1: The generic usb-serial driver is only for testing and one-off prototypes. [ 172.772640] usbserial_generic 1-2.2:1.1: Tell linux-...@vger.kernel.org to add your device to a proper driver. [ 172.783154] usbserial_generic 1-2.2:1.1: generic converter detected [ 172.790765] usb 1-2.2: generic converter now attached to ttyUSB1 [ 172.797235] usbserial_generic 1-2.2:1.2: The generic usb-serial driver is only for testing and one-off prototypes. [ 172.808296] usbserial_generic 1-2.2:1.2: Tell linux-...@vger.kernel.org to add your device to a proper driver. [ 172.818797] usbserial_generic 1-2.2:1.2: generic converter detected [ 172.826135] usb 1-2.2: generic converter now attached to ttyUSB2
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi, Am 01.04.2015 um 22:16 schrieb Pavel Machek : > Hi! > >>> As I explained in some other mail, those tables should not be >>> neccessary at all. They can be computed from li-ion characteristics >>> and internal resistance, and assumed current during charge and >>> discharge. >> >> I already explained that we do not know the charging and discharging >> current well enough for such a calculation. >> >> And I explained that the “internal resistance” is a system (battery + cables >> + >> connectors + other circuits) parameter that is not easy to derive or measure >> and type into the .dts source code. >> >> At least I have no idea how I should find it out for my boards. While I can >> easily determine the curves (and we already have them for the platform_data >> driver). >> >> Please propose your own code doing that so that we can test if it is >> better. > > So, how does this look? > > It looks to me like you have cca 0.1 Ohm resistance in your system, This is completely unknown. > and are using cca 75mA while discharging, and charge by cca 1.4A. Where do you get these figures from? A GTA04 board discharges usually between 50 and 400 mA (depending on activities) and if you turn on WiFi, it will be up to 600 mA. If you use 3G it can draw even more during operation. Total current going in is 500-800 mA (depending on USB negotiations) and this is split into system operation and charging current. So 1.4A charging current is not possible. Rather 200-500 mA. So it might be that the battery is discharged although the system is connected to a charger. > (And > these are all the coefficients the code should need; rest is battery > characteristics -- common to all li-ions, and charger characteristics > -- that will be common to all cellphones. If current can be measured, > this code should go more precise answers). > > pavel@amd:~/g/tui/ofone$ ./liion_maps > Charging > Voltage 4.2 V ; table 100 % internal voltage 4.18 V current 0.233 A > computed 97 % > Voltage 4.1 V ; table 75 % internal voltage 4.08 V current 0.233 A > computed 87 % > Voltage 4.0 V ; table 55 % internal voltage 3.93 V current 0.700 A > computed 69 % > Voltage 3.9 V ; table 25 % internal voltage 3.76 V current 1.400 A > computed 26 % > Voltage 3.8 V ; table 5 % internal voltage 3.66 V current 1.400 A computed > 3 % > Voltage 3.7 V ; table 2 % internal voltage 3.56 V current 1.400 A computed > 2 % > Voltage 3.6 V ; table 1 % internal voltage 3.46 V current 1.400 A computed > 1 % > Voltage 3.3 V ; table 0 % internal voltage 3.16 V current 1.400 A computed > -1 % > Badness 395.4861761427434 > Discharging > Voltage 4.2 V ; table 100 % internal voltage 4.21 V current -0.075 A > computed 100 % > Voltage 4.1 V ; table 95 % internal voltage 4.11 V current -0.075 A > computed 91 % > Voltage 4.0 V ; table 70 % internal voltage 4.01 V current -0.075 A > computed 79 % > Voltage 3.8 V ; table 50 % internal voltage 3.81 V current -0.075 A > computed 46 % > Voltage 3.7 V ; table 10 % internal voltage 3.71 V current -0.075 A > computed 3 % > Voltage 3.6 V ; table 5 % internal voltage 3.61 V current -0.075 A > computed 2 % > Voltage 3.3 V ; table 0 % internal voltage 3.31 V current -0.075 A > computed 0 % > Badness 171.69576218433212 > >>> Running below 3.3V.. not really. At that point, the battery is really >>> _empty_, and voltage is going down really really fast. >> >> It is the diffference between 2% and 0% where a fuel indication might >> be most important… > >>> Plus, you are damaging the battery at that point. >> >> The power controller will shut down - but the driver should report >> reasonable (but IMHO not necessarily perfect) values until the last >> moment. > > It is tricky to do a good job near 0%... or anywhere else. See for > example > > http://cseweb.ucsd.edu/~trosing/lectures/battery.pdf > > You start a call, percentage goes down, end a call, it will go > back up. I'm pretty sure you will not be able to make a call with "5%" > indication from your code at low battery temperature (say -10C). The whole system is heating up a little, so that you never have -10C for the battery. I think you are trying to solve situations that don’t exist in practice. And AFAIK, the GTA04 board is the only user of this driver in case the battery has no built-in fuel gauge. So why improve it beyond what the GTA04 users need? I repeat myself: this driver is not built for highest precision because there are better methods (fuel gauge chip). These might not be available so this fall-back driver has been built. It is definitively better than no driver and worse than the optimum. > > Anyway, see above, I think I provide reasonable values even in that range. > > Signed-off-by: Pavel Machek > Pavel > > #!/usr/bin/python3 > import math > > def percent_internal(v): >u =
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi,
Am 01.04.2015 um 18:30 schrieb Rob Herring :
> On Tue, Mar 10, 2015 at 4:27 PM, Marek Belisko wrote:
>> Signed-off-by: Marek Belisko
>> ---
>> .../bindings/power_supply/twl4030_madc_battery.txt | 43
>> ++
>> 1 file changed, 43 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>> b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>> new file mode 100644
>> index 000..d3dd9d8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
>> @@ -0,0 +1,43 @@
>> +twl4030_madc_battery
>> +
>> +Required properties:
>> + - compatible : "ti,twl4030-madc-battery"
>
> Is this a sub-node of the twl4030 or something? Please define where
> this fits (hint: I would expect to be a sub node of a charging
> controller or battery monitor).
It is a driver connecting some battery parameters with measurements provided
by the twl4030-madc to present a /sys/class/power_supply node for the battery
with a coarse estimate for the charging level.
So maybe the best wording is that it is a battery-driver assuming a twl4030-madc
providing raw measurements (voltage, charging).
Therefore it could as well be battery-twl4030-madc.
>
>> + - capacity-uah : battery capacity in uAh
>> + - ti,volt-to-capacity-charging-map : list of voltage(mV):level(%) values
>> + for charging calibration (see example)
>> + - ti,volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
>> + for discharging calibration (see example)
>
> These seem like properties of the battery independent of the
> battery/charging controller which is the twl4030. Ideally we would
> define battery nodes generically and independent of the charge
> controllers. Then there are smart batteries to consider too.
For smart batteries there are completely independent mechanisms
like I2C and HDQ/1-wire communication with fuel gauge chips (e.g. b27xxx).
Those do not need such battery properties because they are stored
in EEPROMs within these chips.
So all this is a quite special solution just for those handful of board that
have no smart battery and use exactly this twl4030 chip.
It is not intended to become a generic charging/fuel solution. Just
make it work with DT (it worked with platform_data since ~3.12).
BR,
Nikolaus
>
> Rob
>
>> + - io-channels: Should contain IIO channel specifiers
>> + for each element in io-channel-names.
>> +- io-channel-names: Should contain the following values:
>> + * "temp" - The ADC channel for temperature reading
>> + * "ichg" - The ADC channel for battery charging status
>> + * "vbat" - The ADC channel to measure the battery voltage
>> +
>> +Example:
>> + madc-battery {
>> + compatible = "ti,twl4030-madc-battery";
>> + capacity-uah = <120>;
>> + ti,volt-to-capacity-charging-map = <4200 100>,
>> + <4100 75>,
>> + <4000 55>,
>> + <3900 25>,
>> + <3800 5>,
>> + <3700 2>,
>> + <3600 1>,
>> + <3300 0>;
>> +
>> + ti,volt-to-capacity-discharging-map = <4200 100>
>> + <4100 95>,
>> + <4000 70>,
>> + <3800 50>,
>> + <3700 10>,
>> + <3600 5>,
>> + <3300 0>;
>> + io-channels = <_madc 1>,
>> + <_madc 10>,
>> + <_madc 12>;
>> + io-channel-names = "temp",
>> + "ichg",
>> + "vbat";
>> + };
>> --
>> 1.9.1
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi Pavel, Am 31.03.2015 um 09:26 schrieb Pavel Machek : > Hi! > > + io-channels = <_madc 1>, > + <_madc 10>, > + <_madc 12>; > + io-channel-names = "temp", > +"ichg", > +"vbat"; > + }; Rather than just making platform_data into device tree properties.. Can't you hide the these custom properties behind the compatible flag? You can initialize that data in the driver based on the compatible flag and the match data. This makes sense if you can group things to similar configurations. >>> >>> Maybe I have not completely understood your proposal. >>> >>> Do you mean to go back to have big parameter tables for each device/battery >>> combination in the driver code and the compatible flag (e.g. compatible = >>> “board17”) >>> chooses the right data set for the charging map and channels? >> >> If you can somehow group them, then yes. Not for every board if there >> are many of them naturally. >> >>> I thought this is what the DT was introduced for - to have the same driver >>> code but adapt to different boards depending on hardware variations. >> >> Yeah but you also need to consider the issues related to introducing >> new device tree properties. The device tree properties introduced >> should be generic where possible. >> >>> And batteries have very different characteristics and vary between devices… >> >> Right. Maybe that has been already agreed on to use capacity-uah for >> batteries in general? In that case I have not problem with that as >> it's a generic property :) >> >>> The charging maps are depending on the battery type connected to the twl4030 >>> and which madc channel is which value is also a little hardware dependent >>> (although the twl4030 doesn’t give much choice). >> >> Just to consider alternatives before introducing driver specific >> property for the maps.. Maybe here you could have few different type >> of maps and select something safe by default? Of course it could be this >> is higly board specific, I think some devices may be able to run below >> 3.3V for example.. > > As I explained in some other mail, those tables should not be > neccessary at all. They can be computed from li-ion characteristics > and internal resistance, and assumed current during charge and > discharge. I already explained that we do not know the charging and discharging current well enough for such a calculation. And I explained that the “internal resistance” is a system (battery + cables + connectors + other circuits) parameter that is not easy to derive or measure and type into the .dts source code. At least I have no idea how I should find it out for my boards. While I can easily determine the curves (and we already have them for the platform_data driver). Please propose your own code doing that so that we can test if it is better. > > Running below 3.3V.. not really. At that point, the battery is really > _empty_, and voltage is going down really really fast. It is the diffference between 2% and 0% where a fuel indication might be most important… > > Plus, you are damaging the battery at that point. The power controller will shut down - but the driver should report reasonable (but IMHO not necessarily perfect) values until the last moment. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi Pavel, Am 31.03.2015 um 09:26 schrieb Pavel Machek pa...@ucw.cz: Hi! + io-channels = twl_madc 1, + twl_madc 10, + twl_madc 12; + io-channel-names = temp, +ichg, +vbat; + }; Rather than just making platform_data into device tree properties.. Can't you hide the these custom properties behind the compatible flag? You can initialize that data in the driver based on the compatible flag and the match data. This makes sense if you can group things to similar configurations. Maybe I have not completely understood your proposal. Do you mean to go back to have big parameter tables for each device/battery combination in the driver code and the compatible flag (e.g. compatible = “board17”) chooses the right data set for the charging map and channels? If you can somehow group them, then yes. Not for every board if there are many of them naturally. I thought this is what the DT was introduced for - to have the same driver code but adapt to different boards depending on hardware variations. Yeah but you also need to consider the issues related to introducing new device tree properties. The device tree properties introduced should be generic where possible. And batteries have very different characteristics and vary between devices… Right. Maybe that has been already agreed on to use capacity-uah for batteries in general? In that case I have not problem with that as it's a generic property :) The charging maps are depending on the battery type connected to the twl4030 and which madc channel is which value is also a little hardware dependent (although the twl4030 doesn’t give much choice). Just to consider alternatives before introducing driver specific property for the maps.. Maybe here you could have few different type of maps and select something safe by default? Of course it could be this is higly board specific, I think some devices may be able to run below 3.3V for example.. As I explained in some other mail, those tables should not be neccessary at all. They can be computed from li-ion characteristics and internal resistance, and assumed current during charge and discharge. I already explained that we do not know the charging and discharging current well enough for such a calculation. And I explained that the “internal resistance” is a system (battery + cables + connectors + other circuits) parameter that is not easy to derive or measure and type into the .dts source code. At least I have no idea how I should find it out for my boards. While I can easily determine the curves (and we already have them for the platform_data driver). Please propose your own code doing that so that we can test if it is better. Running below 3.3V.. not really. At that point, the battery is really _empty_, and voltage is going down really really fast. It is the diffference between 2% and 0% where a fuel indication might be most important… Plus, you are damaging the battery at that point. The power controller will shut down - but the driver should report reasonable (but IMHO not necessarily perfect) values until the last moment. BR, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi,
Am 01.04.2015 um 18:30 schrieb Rob Herring robherri...@gmail.com:
On Tue, Mar 10, 2015 at 4:27 PM, Marek Belisko ma...@goldelico.com wrote:
Signed-off-by: Marek Belisko ma...@goldelico.com
---
.../bindings/power_supply/twl4030_madc_battery.txt | 43
++
1 file changed, 43 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
diff --git
a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
new file mode 100644
index 000..d3dd9d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
@@ -0,0 +1,43 @@
+twl4030_madc_battery
+
+Required properties:
+ - compatible : ti,twl4030-madc-battery
Is this a sub-node of the twl4030 or something? Please define where
this fits (hint: I would expect to be a sub node of a charging
controller or battery monitor).
It is a driver connecting some battery parameters with measurements provided
by the twl4030-madc to present a /sys/class/power_supply node for the battery
with a coarse estimate for the charging level.
So maybe the best wording is that it is a battery-driver assuming a twl4030-madc
providing raw measurements (voltage, charging).
Therefore it could as well be battery-twl4030-madc.
+ - capacity-uah : battery capacity in uAh
+ - ti,volt-to-capacity-charging-map : list of voltage(mV):level(%) values
+ for charging calibration (see example)
+ - ti,volt-to-capacity-discharging-map : list of voltage(mV):level(%) values
+ for discharging calibration (see example)
These seem like properties of the battery independent of the
battery/charging controller which is the twl4030. Ideally we would
define battery nodes generically and independent of the charge
controllers. Then there are smart batteries to consider too.
For smart batteries there are completely independent mechanisms
like I2C and HDQ/1-wire communication with fuel gauge chips (e.g. b27xxx).
Those do not need such battery properties because they are stored
in EEPROMs within these chips.
So all this is a quite special solution just for those handful of board that
have no smart battery and use exactly this twl4030 chip.
It is not intended to become a generic charging/fuel solution. Just
make it work with DT (it worked with platform_data since ~3.12).
BR,
Nikolaus
Rob
+ - io-channels: Should contain IIO channel specifiers
+ for each element in io-channel-names.
+- io-channel-names: Should contain the following values:
+ * temp - The ADC channel for temperature reading
+ * ichg - The ADC channel for battery charging status
+ * vbat - The ADC channel to measure the battery voltage
+
+Example:
+ madc-battery {
+ compatible = ti,twl4030-madc-battery;
+ capacity-uah = 120;
+ ti,volt-to-capacity-charging-map = 4200 100,
+ 4100 75,
+ 4000 55,
+ 3900 25,
+ 3800 5,
+ 3700 2,
+ 3600 1,
+ 3300 0;
+
+ ti,volt-to-capacity-discharging-map = 4200 100
+ 4100 95,
+ 4000 70,
+ 3800 50,
+ 3700 10,
+ 3600 5,
+ 3300 0;
+ io-channels = twl_madc 1,
+ twl_madc 10,
+ twl_madc 12;
+ io-channel-names = temp,
+ ichg,
+ vbat;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi, Am 01.04.2015 um 22:16 schrieb Pavel Machek pa...@ucw.cz: Hi! As I explained in some other mail, those tables should not be neccessary at all. They can be computed from li-ion characteristics and internal resistance, and assumed current during charge and discharge. I already explained that we do not know the charging and discharging current well enough for such a calculation. And I explained that the “internal resistance” is a system (battery + cables + connectors + other circuits) parameter that is not easy to derive or measure and type into the .dts source code. At least I have no idea how I should find it out for my boards. While I can easily determine the curves (and we already have them for the platform_data driver). Please propose your own code doing that so that we can test if it is better. So, how does this look? It looks to me like you have cca 0.1 Ohm resistance in your system, This is completely unknown. and are using cca 75mA while discharging, and charge by cca 1.4A. Where do you get these figures from? A GTA04 board discharges usually between 50 and 400 mA (depending on activities) and if you turn on WiFi, it will be up to 600 mA. If you use 3G it can draw even more during operation. Total current going in is 500-800 mA (depending on USB negotiations) and this is split into system operation and charging current. So 1.4A charging current is not possible. Rather 200-500 mA. So it might be that the battery is discharged although the system is connected to a charger. (And these are all the coefficients the code should need; rest is battery characteristics -- common to all li-ions, and charger characteristics -- that will be common to all cellphones. If current can be measured, this code should go more precise answers). pavel@amd:~/g/tui/ofone$ ./liion_maps Charging Voltage 4.2 V ; table 100 % internal voltage 4.18 V current 0.233 A computed 97 % Voltage 4.1 V ; table 75 % internal voltage 4.08 V current 0.233 A computed 87 % Voltage 4.0 V ; table 55 % internal voltage 3.93 V current 0.700 A computed 69 % Voltage 3.9 V ; table 25 % internal voltage 3.76 V current 1.400 A computed 26 % Voltage 3.8 V ; table 5 % internal voltage 3.66 V current 1.400 A computed 3 % Voltage 3.7 V ; table 2 % internal voltage 3.56 V current 1.400 A computed 2 % Voltage 3.6 V ; table 1 % internal voltage 3.46 V current 1.400 A computed 1 % Voltage 3.3 V ; table 0 % internal voltage 3.16 V current 1.400 A computed -1 % Badness 395.4861761427434 Discharging Voltage 4.2 V ; table 100 % internal voltage 4.21 V current -0.075 A computed 100 % Voltage 4.1 V ; table 95 % internal voltage 4.11 V current -0.075 A computed 91 % Voltage 4.0 V ; table 70 % internal voltage 4.01 V current -0.075 A computed 79 % Voltage 3.8 V ; table 50 % internal voltage 3.81 V current -0.075 A computed 46 % Voltage 3.7 V ; table 10 % internal voltage 3.71 V current -0.075 A computed 3 % Voltage 3.6 V ; table 5 % internal voltage 3.61 V current -0.075 A computed 2 % Voltage 3.3 V ; table 0 % internal voltage 3.31 V current -0.075 A computed 0 % Badness 171.69576218433212 Running below 3.3V.. not really. At that point, the battery is really _empty_, and voltage is going down really really fast. It is the diffference between 2% and 0% where a fuel indication might be most important… Plus, you are damaging the battery at that point. The power controller will shut down - but the driver should report reasonable (but IMHO not necessarily perfect) values until the last moment. It is tricky to do a good job near 0%... or anywhere else. See for example http://cseweb.ucsd.edu/~trosing/lectures/battery.pdf You start a call, percentage goes down, end a call, it will go back up. I'm pretty sure you will not be able to make a call with 5% indication from your code at low battery temperature (say -10C). The whole system is heating up a little, so that you never have -10C for the battery. I think you are trying to solve situations that don’t exist in practice. And AFAIK, the GTA04 board is the only user of this driver in case the battery has no built-in fuel gauge. So why improve it beyond what the GTA04 users need? I repeat myself: this driver is not built for highest precision because there are better methods (fuel gauge chip). These might not be available so this fall-back driver has been built. It is definitively better than no driver and worse than the optimum. Anyway, see above, I think I provide reasonable values even in that range. Signed-off-by: Pavel Machek pa...@ucw.cz Pavel #!/usr/bin/python3 import math def percent_internal(v): u = 0.0387-(1.4523*(3.7835-v)) if u 0: # Formula above does gives 19.66% for 3.756, and refuses to # work below that.
Re: [Gta04-owner] [PATCH] Documentation: usb: serial: fixed how to provide vendor and product id
Am 30.03.2015 um 11:32 schrieb Dr. H. Nikolaus Schaller : > Hi Johan, > > Am 30.03.2015 um 09:45 schrieb Johan Hovold : > >> On Sat, Mar 28, 2015 at 02:37:57PM +0100, Marek Belisko wrote: >>> From: "H. Nikolaus Schaller" >>> >>> While trying to test the Pyra GSM/GPS/3G module I had reconfigured >>> the USB interface by mistake and therefore needed to run a different >>> USB driver than CSC-ACM. It turned out that I need the "usbserial" driver. >> >> CDC-ACM > > oh, thanks. There is always at least one more typo in any document… > >> >>> This file is an official description how to use it: >>> Documentation/usb/usb-serial.txt >>> >>> But it is outdated. The parameters vendor= and product= are no longer >>> available since ca. 3.12 which means that documentation is lagging behind >>> quite some time. >> >> This is simply not true. The vendor and module parameters are still >> there for usbserial (i.e. the generic driver). >> >> Would you mind updating this patch to document the sysfs-method as an >> alternative instead? Using sysfs is preferred as that functionality can >> be used with any usb-serial driver and the drivers can also be compiled >> in. > > Hm. For me it did not work as described and therefore I searched for > and found the solution cited below, which appears to confirm that it does > not work any more. Only with these hints to use the /sys approach I > could make it working immediately. > > Therefore I assumed that the documentation is outdated. > > But it might also be a hidden bug with the parameter passing. > I had tested on 4.0-rc3. > > I can try a little more but it might be waste of time to find out why the old > does not work, if there is a preferred method now. > >> >>> Here was the solution: >>> >>> https://bbs.archlinux.org/viewtopic.php?id=175499 >>> >>> insmod usbserial vendor=0x product=0x >>> >>> becomes (first is vendor, second is product) >>> >>> modprobe usbserial >>> echo >/sys/bus/usb-serial/drivers/generic/new_id >>> >>> This patch changes the documentation file as needed. >>> >>> Signed-off-by: H. Nikolaus Schaller >>> Signed-off-by: Marek Belisko >>> --- >>> Documentation/usb/usb-serial.txt | 12 +++- >>> 1 file changed, 7 insertions(+), 5 deletions(-) >>> >>> diff --git a/Documentation/usb/usb-serial.txt >>> b/Documentation/usb/usb-serial.txt >>> index 947fa62..9f184d8 100644 >>> --- a/Documentation/usb/usb-serial.txt >>> +++ b/Documentation/usb/usb-serial.txt >>> @@ -466,11 +466,13 @@ Generic Serial driver >>> is required of your device is that it has at least one bulk in endpoint, >>> or one bulk out endpoint. >>> >>> - To enable the generic driver to recognize your device, build the driver >>> - as a module and load it by the following invocation: >>> - insmod usbserial vendor=0x product=0x >>> - where the is replaced with the hex representation of your device's >>> - vendor id and product id. >>> + To enable the generic driver to recognize your device, configure >>> + USB_SERIAL_GENERIC=y and build the driver as a module. Then load it by >>> the >> >> You don't need to build the driver as a module when using the sysfs >> method. > > Ok, that is right and my formulation is too narrow on that. Well, I should add that not my formulation was too narrow but already the original. > > So we just s/ as a module//. > >> >>> + following invocation: >>> + modprobe usbserial >>> + echo >/sys/bus/usb-serial/drivers/generic/new_id >>> + where the the first is replaced with the hex representation of your >>> + device's vendor id and the second by the product id. >>> >>> This driver has been successfully used to connect to the NetChip USB >>> development board, providing a way to develop USB firmware without >> >> Thanks, >> Johan > > Thanks as well, > Nikolaus > > > ___ > 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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: usb: serial: fixed how to provide vendor and product id
Hi Johan, Am 30.03.2015 um 09:45 schrieb Johan Hovold : > On Sat, Mar 28, 2015 at 02:37:57PM +0100, Marek Belisko wrote: >> From: "H. Nikolaus Schaller" >> >> While trying to test the Pyra GSM/GPS/3G module I had reconfigured >> the USB interface by mistake and therefore needed to run a different >> USB driver than CSC-ACM. It turned out that I need the "usbserial" driver. > > CDC-ACM oh, thanks. There is always at least one more typo in any document… > >> This file is an official description how to use it: >> Documentation/usb/usb-serial.txt >> >> But it is outdated. The parameters vendor= and product= are no longer >> available since ca. 3.12 which means that documentation is lagging behind >> quite some time. > > This is simply not true. The vendor and module parameters are still > there for usbserial (i.e. the generic driver). > > Would you mind updating this patch to document the sysfs-method as an > alternative instead? Using sysfs is preferred as that functionality can > be used with any usb-serial driver and the drivers can also be compiled > in. Hm. For me it did not work as described and therefore I searched for and found the solution cited below, which appears to confirm that it does not work any more. Only with these hints to use the /sys approach I could make it working immediately. Therefore I assumed that the documentation is outdated. But it might also be a hidden bug with the parameter passing. I had tested on 4.0-rc3. I can try a little more but it might be waste of time to find out why the old does not work, if there is a preferred method now. > >> Here was the solution: >> >> https://bbs.archlinux.org/viewtopic.php?id=175499 >> >> insmod usbserial vendor=0x product=0x >> >> becomes (first is vendor, second is product) >> >> modprobe usbserial >> echo >/sys/bus/usb-serial/drivers/generic/new_id >> >> This patch changes the documentation file as needed. >> >> Signed-off-by: H. Nikolaus Schaller >> Signed-off-by: Marek Belisko >> --- >> Documentation/usb/usb-serial.txt | 12 +++- >> 1 file changed, 7 insertions(+), 5 deletions(-) >> >> diff --git a/Documentation/usb/usb-serial.txt >> b/Documentation/usb/usb-serial.txt >> index 947fa62..9f184d8 100644 >> --- a/Documentation/usb/usb-serial.txt >> +++ b/Documentation/usb/usb-serial.txt >> @@ -466,11 +466,13 @@ Generic Serial driver >> is required of your device is that it has at least one bulk in endpoint, >> or one bulk out endpoint. >> >> - To enable the generic driver to recognize your device, build the driver >> - as a module and load it by the following invocation: >> -insmod usbserial vendor=0x product=0x >> - where the is replaced with the hex representation of your device's >> - vendor id and product id. >> + To enable the generic driver to recognize your device, configure >> + USB_SERIAL_GENERIC=y and build the driver as a module. Then load it by the > > You don't need to build the driver as a module when using the sysfs > method. Ok, that is right and my formulation is too narrow on that. So we just s/ as a module//. > >> + following invocation: >> +modprobe usbserial >> +echo >/sys/bus/usb-serial/drivers/generic/new_id >> + where the the first is replaced with the hex representation of your >> + device's vendor id and the second by the product id. >> >> This driver has been successfully used to connect to the NetChip USB >> development board, providing a way to develop USB firmware without > > Thanks, > Johan Thanks as well, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: usb: serial: fixed how to provide vendor and product id
Hi Johan, Am 30.03.2015 um 09:45 schrieb Johan Hovold jo...@kernel.org: On Sat, Mar 28, 2015 at 02:37:57PM +0100, Marek Belisko wrote: From: H. Nikolaus Schaller h...@goldelico.com While trying to test the Pyra GSM/GPS/3G module I had reconfigured the USB interface by mistake and therefore needed to run a different USB driver than CSC-ACM. It turned out that I need the usbserial driver. CDC-ACM oh, thanks. There is always at least one more typo in any document… This file is an official description how to use it: Documentation/usb/usb-serial.txt But it is outdated. The parameters vendor= and product= are no longer available since ca. 3.12 which means that documentation is lagging behind quite some time. This is simply not true. The vendor and module parameters are still there for usbserial (i.e. the generic driver). Would you mind updating this patch to document the sysfs-method as an alternative instead? Using sysfs is preferred as that functionality can be used with any usb-serial driver and the drivers can also be compiled in. Hm. For me it did not work as described and therefore I searched for and found the solution cited below, which appears to confirm that it does not work any more. Only with these hints to use the /sys approach I could make it working immediately. Therefore I assumed that the documentation is outdated. But it might also be a hidden bug with the parameter passing. I had tested on 4.0-rc3. I can try a little more but it might be waste of time to find out why the old does not work, if there is a preferred method now. Here was the solution: https://bbs.archlinux.org/viewtopic.php?id=175499 insmod usbserial vendor=0x product=0x becomes (first is vendor, second is product) modprobe usbserial echo /sys/bus/usb-serial/drivers/generic/new_id This patch changes the documentation file as needed. Signed-off-by: H. Nikolaus Schaller h...@goldelico.com Signed-off-by: Marek Belisko ma...@goldelico.com --- Documentation/usb/usb-serial.txt | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt index 947fa62..9f184d8 100644 --- a/Documentation/usb/usb-serial.txt +++ b/Documentation/usb/usb-serial.txt @@ -466,11 +466,13 @@ Generic Serial driver is required of your device is that it has at least one bulk in endpoint, or one bulk out endpoint. - To enable the generic driver to recognize your device, build the driver - as a module and load it by the following invocation: -insmod usbserial vendor=0x product=0x - where the is replaced with the hex representation of your device's - vendor id and product id. + To enable the generic driver to recognize your device, configure + USB_SERIAL_GENERIC=y and build the driver as a module. Then load it by the You don't need to build the driver as a module when using the sysfs method. Ok, that is right and my formulation is too narrow on that. So we just s/ as a module//. + following invocation: +modprobe usbserial +echo /sys/bus/usb-serial/drivers/generic/new_id + where the the first is replaced with the hex representation of your + device's vendor id and the second by the product id. This driver has been successfully used to connect to the NetChip USB development board, providing a way to develop USB firmware without Thanks, Johan Thanks as well, Nikolaus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH] Documentation: usb: serial: fixed how to provide vendor and product id
Am 30.03.2015 um 11:32 schrieb Dr. H. Nikolaus Schaller h...@goldelico.com: Hi Johan, Am 30.03.2015 um 09:45 schrieb Johan Hovold jo...@kernel.org: On Sat, Mar 28, 2015 at 02:37:57PM +0100, Marek Belisko wrote: From: H. Nikolaus Schaller h...@goldelico.com While trying to test the Pyra GSM/GPS/3G module I had reconfigured the USB interface by mistake and therefore needed to run a different USB driver than CSC-ACM. It turned out that I need the usbserial driver. CDC-ACM oh, thanks. There is always at least one more typo in any document… This file is an official description how to use it: Documentation/usb/usb-serial.txt But it is outdated. The parameters vendor= and product= are no longer available since ca. 3.12 which means that documentation is lagging behind quite some time. This is simply not true. The vendor and module parameters are still there for usbserial (i.e. the generic driver). Would you mind updating this patch to document the sysfs-method as an alternative instead? Using sysfs is preferred as that functionality can be used with any usb-serial driver and the drivers can also be compiled in. Hm. For me it did not work as described and therefore I searched for and found the solution cited below, which appears to confirm that it does not work any more. Only with these hints to use the /sys approach I could make it working immediately. Therefore I assumed that the documentation is outdated. But it might also be a hidden bug with the parameter passing. I had tested on 4.0-rc3. I can try a little more but it might be waste of time to find out why the old does not work, if there is a preferred method now. Here was the solution: https://bbs.archlinux.org/viewtopic.php?id=175499 insmod usbserial vendor=0x product=0x becomes (first is vendor, second is product) modprobe usbserial echo /sys/bus/usb-serial/drivers/generic/new_id This patch changes the documentation file as needed. Signed-off-by: H. Nikolaus Schaller h...@goldelico.com Signed-off-by: Marek Belisko ma...@goldelico.com --- Documentation/usb/usb-serial.txt | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt index 947fa62..9f184d8 100644 --- a/Documentation/usb/usb-serial.txt +++ b/Documentation/usb/usb-serial.txt @@ -466,11 +466,13 @@ Generic Serial driver is required of your device is that it has at least one bulk in endpoint, or one bulk out endpoint. - To enable the generic driver to recognize your device, build the driver - as a module and load it by the following invocation: - insmod usbserial vendor=0x product=0x - where the is replaced with the hex representation of your device's - vendor id and product id. + To enable the generic driver to recognize your device, configure + USB_SERIAL_GENERIC=y and build the driver as a module. Then load it by the You don't need to build the driver as a module when using the sysfs method. Ok, that is right and my formulation is too narrow on that. Well, I should add that not my formulation was too narrow but already the original. So we just s/ as a module//. + following invocation: + modprobe usbserial + echo /sys/bus/usb-serial/drivers/generic/new_id + where the the first is replaced with the hex representation of your + device's vendor id and the second by the product id. This driver has been successfully used to connect to the NetChip USB development board, providing a way to develop USB firmware without Thanks, Johan Thanks as well, Nikolaus ___ 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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Am 27.03.2015 um 17:31 schrieb Sebastian Reichel : > Hi, > > On Fri, Mar 27, 2015 at 10:22:11AM +0100, Dr. H. Nikolaus Schaller wrote: >>> Coming back at my sentence: I asked about a non-trivial, non-bus >>> connected HW, which has a DT binding. >> >> from omap3-beagle-xm.dts: >> hsusb2_phy (connected through ULPI) >> gpio-keys (it is not a trivial on/off) >> tfp410 (DVI encoder only part of the video pipeline) > > These just need a couple of gpios. For me that's trivial compared to > an interface as complex as UART. Since they do not have any complex > interface they could be a child of, they must land in /. ULPI-PHY is not at all “just a couple of GPIOs”. It is a 60 MHz 8 bit wide parallel protocol with handshake… Sort of 8 UARTs or SPI with common clock. But still no bus. The bus driven by the ULPI-PHY is “USB2” which is known not to be a physical bus but a tree. It just becomes a bus by higher level protocols. I must admit that I lost the goal that you want to demonstrate with this question/examples. > >> sound/codec (connected through McBSPs) > > The audio codec is a child device of the TWL. The node you are > talking about is a ***virtual*** device. Ah interesting that they exist! A virtual gpio was not acceptable… > See also > > http://devicetree.org/SoC_Audio > > Note that the audio binding of many devices is not that "clean", > since quite some relationships are hidden away behind kernel quirks > and very specific compatible strings. > >> and there are components on the board which are not described at >> all but work out of the box: audio connectors, usb/ethernet hub > > Sure. Everything that can be identified automatically (USB/Ethernet > stuff) is not encoded into DT. DT has been created to provide a > description for devices, which can *not* be identified automatically. Exactly. > > And passive components like audio connectors are normally not > encoded into DT, since no configuration is needed and no information > is gained. Before you argument with video connectors: Yes they are > different, but IMHO for good reasons: > > 1. The user can see "DVI" label for DVI output and "HDMI" label > for HDMI output. This is not known by the display controller. > 2. The display data channel is i2c and the connector may use a > system i2c controller together with the data wires provided by > the display controller. The display subsystem must know which > i2c controller takes care of the port. Yes. Indeed. > >> In the meantime, I have proposed an IMHO even better approach. >> >> It is not to make the gps a regulator or a subnode of some “primary >> interface”, >> but give it a reference to the uart it is connected to. >> >> And make it an independent node on DT root level. >> >> Then we are completely independent on how the gps driver presents >> data to any user space on any OS. > > IMHO that approach is not better per se. The child variant is more > generic it contains information without the kernel even knowing > about uart specific stuff. > > Note, that we could always use references in DT. The tree structure > is not needed at all, since references make it possible to describe > a graph. Right. > Obviously that would defeat the purpose of the tree > structure. Which might be there for completeness if something wants to be better described in a tree structure. Multiple clients of a single bus controller that can be selected (addressed) are obviously better described by a parent>child relationship (which includes some sort of “address” to describe how this addressing works). > In my opinion making something a node in / is always the > last resort and in my perspective it has been handled in such a way > so far. But that contradicts some documents I have found and linked. Please show me a document about DT that supports your view. I agree that both views can be valid, but in lack of some “official” guideline we can’t decide ourselves. > >> What is bad with having a net? Why must we squeeze everything into >> a tree structure just because it is called such? DT language >> provides the syntax for references and that allows to make nets. >> And it is heavily used. > > I think so far references were mainly used when tree structure was > too limited to describe something. > >>>> You said NAK about referencing a regulator from the UART node and >>>> now? >>> >>> No. I said NAK about referencing *the* regulator from the BT/GPS >>> node. My NAK was about referencing a regulator in the UART node >>> (local side), which is actually needed by the GPS/BT module (remot
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi, Am 26.03.2015 um 19:08 schrieb Sebastian Reichel : > Hi, > > On Wed, Mar 25, 2015 at 05:44:42PM +0100, Dr. H. Nikolaus Schaller wrote: >> Am 25.03.2015 um 16:21 schrieb Sebastian Reichel : >>> On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote: >>>> Am 25.03.2015 um 02:45 schrieb Sebastian Reichel : >>>>> On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote: >>>>>> So you propose that the parent->child relationship is “control”? I.e. >>>>>> some >>>>>> channel which allows to address some bus client (through ) and >>>>>> control that devices. >>>>>> >>>>>> Makes sense. This is how i2c and spi clients are specified. >>>>>> >>>>>>> In the case of our GPS, it receives control over the serial connection >>>>>>> from >>>>>>> the UART, >>>>>> >>>>>> Ahem - does it? >>>>>> >>>>>> AFAIK the chip simply starts to emit NMEA records if powered on. >>>>>> There is no command going over the serial interface to address it >>>>>> or control it. >>>>> >>>>> Right, since GPS basically doesn't need any configuration/control. >>>>> That’s not true for other UART attached devices, though. >>>> >>>> Do you have an example? Usually an UART data stream is transparently >>>> presented to a /dev/tty - and user-space daemon can configure/control the >>>> attached device. In most cases it can mix payload data and control command >>>> by some AT command and escape sequences. >>> >>> Yes, but the configuration is minimal. Anyways as you said there >>> *is* some kind of control happening over the UART. >> >> Control is happening on a higher network stack level than UART. It >> control is done through AT commands. > > Yes, obviously UART is only the physical layer. The same is true for > busses and does not really matter. Fine that we agree on that. I just mentioned it because we discussed about line disciplines and tty which are higher level. > >>>>>>> also receives control via a GPIO to the on/off pin, and also needs >>>>>>> a regulator to power the antenna. >>>>>>> >>>>>>> So should the parent be the uart, the on/off GPIO, or the regulator? >>>>>>> >>>>>>> I would much rather there wasn't a parent, and that each of these were >>>>>>> listed >>>>>>> as ad-hoc attribute assignments. But device-tree says there must be a >>>>>>> parent >>>>>>> (where possible), and the parent is the thing that is “primarily" in >>>>>>> control. >>>>>> >>>>>> Well, IMHO the “parent” could also be the root. Representing the >>>>>> whole board. >>>>>> >>>>>> Nevertheless, I doubt your rule that “ability to control” defines >>>>>> the parent>child relation (see below). >>>>>> >>>>>>> >>>>>>> I think the GPS is “primarily" a uart-attached device. >>>>>> >>>>>> But not in the same way as an I2C device. >>>>>> >>>>>> Especially the serial interface is not a bus and not used for >>>>>> signalling and power control. It is payload data (only). >>>>> >>>>> Actually many I2C devices are also powered on/off via a GPIO and >>>>> even use additional GPIOs for sending interrupts. Nevertheless they >>>>> are normally identified as an I2C device. >>>> >>>> Because I2C is a bus that can address multiple clients and gpio isn’t >>>> a bus and a point-to-point connection. >>>> >>>> But IMHO it is not because they (can) send payload data over i2c. >>> >>> From my POV it's not because I2C is a bus, but because the primary >>> function is happening via I2C (e.g. configuring sensor, gettings its >>> data). The GPIOs are only needed to compensate some I2C shortcomings >>> (missing irq feature in I2C) or reduce the complexity of the client >>> (power GPIO). The actual system interaction with the I2C chip is >>> going via I2C, though. >> >> Yes, but this is in my new understanding irrelevant for proper DT >>
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi,
Am 26.03.2015 um 19:08 schrieb Sebastian Reichel s...@kernel.org:
Hi,
On Wed, Mar 25, 2015 at 05:44:42PM +0100, Dr. H. Nikolaus Schaller wrote:
Am 25.03.2015 um 16:21 schrieb Sebastian Reichel s...@kernel.org:
On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote:
Am 25.03.2015 um 02:45 schrieb Sebastian Reichel s...@kernel.org:
On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
So you propose that the parent-child relationship is “control”? I.e.
some
channel which allows to address some bus client (through reg) and
control that devices.
Makes sense. This is how i2c and spi clients are specified.
In the case of our GPS, it receives control over the serial connection
from
the UART,
Ahem - does it?
AFAIK the chip simply starts to emit NMEA records if powered on.
There is no command going over the serial interface to address it
or control it.
Right, since GPS basically doesn't need any configuration/control.
That’s not true for other UART attached devices, though.
Do you have an example? Usually an UART data stream is transparently
presented to a /dev/tty - and user-space daemon can configure/control the
attached device. In most cases it can mix payload data and control command
by some AT command and escape sequences.
Yes, but the configuration is minimal. Anyways as you said there
*is* some kind of control happening over the UART.
Control is happening on a higher network stack level than UART. It
control is done through AT commands.
Yes, obviously UART is only the physical layer. The same is true for
busses and does not really matter.
Fine that we agree on that. I just mentioned it because we discussed about line
disciplines and tty which are higher level.
also receives control via a GPIO to the on/off pin, and also needs
a regulator to power the antenna.
So should the parent be the uart, the on/off GPIO, or the regulator?
I would much rather there wasn't a parent, and that each of these were
listed
as ad-hoc attribute assignments. But device-tree says there must be a
parent
(where possible), and the parent is the thing that is “primarily in
control.
Well, IMHO the “parent” could also be the root. Representing the
whole board.
Nevertheless, I doubt your rule that “ability to control” defines
the parentchild relation (see below).
I think the GPS is “primarily a uart-attached device.
But not in the same way as an I2C device.
Especially the serial interface is not a bus and not used for
signalling and power control. It is payload data (only).
Actually many I2C devices are also powered on/off via a GPIO and
even use additional GPIOs for sending interrupts. Nevertheless they
are normally identified as an I2C device.
Because I2C is a bus that can address multiple clients and gpio isn’t
a bus and a point-to-point connection.
But IMHO it is not because they (can) send payload data over i2c.
From my POV it's not because I2C is a bus, but because the primary
function is happening via I2C (e.g. configuring sensor, gettings its
data). The GPIOs are only needed to compensate some I2C shortcomings
(missing irq feature in I2C) or reduce the complexity of the client
(power GPIO). The actual system interaction with the I2C chip is
going via I2C, though.
Yes, but this is in my new understanding irrelevant for proper DT
description.
And for my understanding it is. We are arguing in a circle…
Yes, and that is the reason why I try to go to a higher level of discussion.
I.e.
find out the principles behind. If we can agree on those, it becomes easy
to decide the details.
If you assume that parentchild relationship is about control (only).
But if it
is about data flow, there is a different concept in DT. For example the
CSI/DSI
(OMAP DSS) use the “port” concept.
Yes, this is about data not going to the cpu / system memory.
Really? The frame buffer data is in system memory and gets to the panel.
Or a
camera image ends up in system memory.
Really? So the panel accesses the system memory? Check again. The
panel is simply connected via DSI/SDI/... and does not access the
system memory at all. The display controller OTH does. So let's have
a look at the DT structure (simplified):
ocp - dss - { port = panel; }
... - spi - panel { port = dss; }
So the port models a device-to-device connection, which works
independent of the remaining system. No system memory is involved.
Sorry, but I can’t exactly follow what you want to show.
Yes, the port mechanism describes a device to device connection.
But it does not describe system memory. Although it is the source of
the video (i.e. the framebuffer).
This shows that the DT does not necessarily describe data flow.
So why do you want to describe data flow from tty to uart to some
connected device?
It shows, that the tree models system memory flow and adds
references for stuff
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Am 27.03.2015 um 17:31 schrieb Sebastian Reichel s...@kernel.org:
Hi,
On Fri, Mar 27, 2015 at 10:22:11AM +0100, Dr. H. Nikolaus Schaller wrote:
Coming back at my sentence: I asked about a non-trivial, non-bus
connected HW, which has a DT binding.
from omap3-beagle-xm.dts:
hsusb2_phy (connected through ULPI)
gpio-keys (it is not a trivial on/off)
tfp410 (DVI encoder only part of the video pipeline)
These just need a couple of gpios. For me that's trivial compared to
an interface as complex as UART. Since they do not have any complex
interface they could be a child of, they must land in /.
ULPI-PHY is not at all “just a couple of GPIOs”. It is a 60 MHz 8 bit wide
parallel protocol with handshake… Sort of 8 UARTs or SPI with common clock.
But still no bus. The bus driven by the ULPI-PHY is “USB2” which is known
not to be a physical bus but a tree. It just becomes a bus by higher level
protocols.
I must admit that I lost the goal that you want to demonstrate with this
question/examples.
sound/codec (connected through McBSPs)
The audio codec is a child device of the TWL. The node you are
talking about is a ***virtual*** device.
Ah interesting that they exist! A virtual gpio was not acceptable…
See also
http://devicetree.org/SoC_Audio
Note that the audio binding of many devices is not that clean,
since quite some relationships are hidden away behind kernel quirks
and very specific compatible strings.
and there are components on the board which are not described at
all but work out of the box: audio connectors, usb/ethernet hub
Sure. Everything that can be identified automatically (USB/Ethernet
stuff) is not encoded into DT. DT has been created to provide a
description for devices, which can *not* be identified automatically.
Exactly.
And passive components like audio connectors are normally not
encoded into DT, since no configuration is needed and no information
is gained. Before you argument with video connectors: Yes they are
different, but IMHO for good reasons:
1. The user can see DVI label for DVI output and HDMI label
for HDMI output. This is not known by the display controller.
2. The display data channel is i2c and the connector may use a
system i2c controller together with the data wires provided by
the display controller. The display subsystem must know which
i2c controller takes care of the port.
Yes. Indeed.
In the meantime, I have proposed an IMHO even better approach.
It is not to make the gps a regulator or a subnode of some “primary
interface”,
but give it a reference to the uart it is connected to.
And make it an independent node on DT root level.
Then we are completely independent on how the gps driver presents
data to any user space on any OS.
IMHO that approach is not better per se. The child variant is more
generic it contains information without the kernel even knowing
about uart specific stuff.
Note, that we could always use references in DT. The tree structure
is not needed at all, since references make it possible to describe
a graph.
Right.
Obviously that would defeat the purpose of the tree
structure.
Which might be there for completeness if something wants to be
better described in a tree structure. Multiple clients of a single bus
controller
that can be selected (addressed) are obviously better described by
a parentchild relationship (which includes some sort of “address”
to describe how this addressing works).
In my opinion making something a node in / is always the
last resort and in my perspective it has been handled in such a way
so far.
But that contradicts some documents I have found and linked. Please
show me a document about DT that supports your view.
I agree that both views can be valid, but in lack of some “official” guideline
we can’t decide ourselves.
What is bad with having a net? Why must we squeeze everything into
a tree structure just because it is called such? DT language
provides the syntax for references and that allows to make nets.
And it is heavily used.
I think so far references were mainly used when tree structure was
too limited to describe something.
You said NAK about referencing a regulator from the UART node and
now?
No. I said NAK about referencing *the* regulator from the BT/GPS
node. My NAK was about referencing a regulator in the UART node
(local side), which is actually needed by the GPS/BT module (remote
side).
Ah, now I understand your argument, and agree to it.
My comment was on a slightly different topic that the DTR line from the
UART (node) can be used to signal the remote regulator to be turned on.
But I learned yesterday that we can even hide this explicit signalling
mechanism (being regulator, gpio or whatever) by:
bt {
compatible = “vendor,btchip”;
regulator = regulator to power the btchip;
uart = uart1;
gpio = gpio to enable the chip;
};
uart1
Re: [PATCH] Documentation: usb: serial: fixed how to provide vendor and product id
Am 26.03.2015 um 11:41 schrieb Belisko Marek : > On Thu, Mar 26, 2015 at 10:53 AM, Greg KH wrote: >> On Wed, Mar 25, 2015 at 09:53:34PM +0100, Marek Belisko wrote: >>> From: "H. Nikolaus Schaller" >>> >>> While trying to test the Pyra GSM/GPS/3G module I had reconfigured >>> the USB interface by mistake and therefore needed to run a different >>> USB driver than CSC-ACM. It turned out that I need the "usbserial" driver. >>> >>> This file is an official description how to use it: >>> Documentation/usb/usb-serial.txt >>> >>> But it is outdated. The parameters vendor= and product= are no longer >>> available since ca. 3.12 which means that documentation is lagging behind >>> quite some time. >>> >>> Here was the solution: >>> >>> https://bbs.archlinux.org/viewtopic.php?id=175499 >>> >>> insmod usbserial vendor=0x product=0x >>> >>> becomes (first is vendor, second is product) >>> >>> modprobe usbserial >>> echo >/sys/bus/usb-serial/drivers/generic/new_id >>> >>> This patch changes the documentation file as needed. >>> >>> Signed-off-by: H. Nikolaus Schaller >> >> You are forwarding on a patch from someone else, why didn't you also >> sign-off on it? Do you not agree with it? > I wasn’t involved in patch development I just review it and forward. Yes, I asked Marek to submit this patch (from our local repo). BR, Nikolaus >> >> thanks, >> >> greg k-h > > 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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi,
Am 26.03.2015 um 06:56 schrieb Pavel Machek :
> Hi!
>
> Main reason is, that I would need to go
> through the UART to “communicate" with the w2sg0004.
You can always "communicate” through the UART. Even without DT. As long as
the connected chip is powered up by any means (could be some
fixed-regulator
or hard wired).
>>>
>>> But you don't know "how" to communicate through the uart.
>>
>> Maybe we are talking using different assumptions. As long as you have a user
>> space
>> gpsd daemon that talks to the gps chip the kernel simply has to
>> transparently (except
>> line disciplines) pass the data to the uart.
>
> Forget userspace, some other operating system (or future linux) may
> want to put gps handling into the kernel. (To hide differences between
> different GPSes).
>
>>> Because we want the phone to boot knowing "I have a bluetooth" or "I
>>> have a GPS", as it would if it was connected using USB, and not having
>>> user figure out what commands he needs to do to enable reasonable
>>> hardware support (and getting it wrong, because you need to specify
>>> _many_ critical parameters to hciattach).
>>
>> Yes, this is indeed something I also would like to see for the GTA04 (and
>> other)
>> devices.
>>
>> So the reason is that some kernel driver wants to use the tty/uart to
>> communicate
>> directly with the chip. This is very similar to a gpio that some driver
>> wants to use.
>>
>> Thus please consider the
>>
>> / {
>> bt {
>> compatible = "vendor,product“;
>> uart = <>;
>> enable = < 34 0>;
>> };
>> };
>
> Would work, too, but I and everyone knows that subnode is better,
> easier solution.
“Everyone” could be wrong and ignorant.
And I thought we are not looking for the easiest solution but the right one.
Especially if we define something that is for other operating systems as well.
About easier: the one given above allows to modify the driver to present e.g.
an iio
interface to user space (and no /dev/tty) *without changing the DT*. Because the
driver code decides which interface it presents. And not where it is a subnode
in DT.
This is the level of abstraction DT nodes should have.
It may be that you did not read my previous argumentation completely.
In short, please see:
http://www.devicetree.org/Device_Tree_Usage#Devices
And check of there is anything that mandates useage of a subnode in this case.
I simply don’t find it.
Rather, although it is also not explicitly excluded, I read hints that it
should *not* be
done the subnode way.
The reason is that it appears to me that the DT hierarchy is intended to
describe
how kernel drivers can *address* different components. Nothing less and nothing
more.
Especially there is no hint that layering in DT has anything to do with data
flow
hierarchies or a “primary” interface as Sebastian calls it.
>
>> approach.
>>
>> And if you want to hide uart1 from the user-space, that should be a property
>> of the uart1 node (whereever it is defined).
>
> Sorry? That would be one heck of layering violation.
Which layering?
I think you still mix the software/kernel driver/data flow layers with DT
layers.
DT can and must be independent on that.
BR,
Nikolaus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Documentation: usb: serial: fixed how to provide vendor and product id
Am 26.03.2015 um 11:41 schrieb Belisko Marek marek.beli...@gmail.com: On Thu, Mar 26, 2015 at 10:53 AM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Mar 25, 2015 at 09:53:34PM +0100, Marek Belisko wrote: From: H. Nikolaus Schaller h...@goldelico.com While trying to test the Pyra GSM/GPS/3G module I had reconfigured the USB interface by mistake and therefore needed to run a different USB driver than CSC-ACM. It turned out that I need the usbserial driver. This file is an official description how to use it: Documentation/usb/usb-serial.txt But it is outdated. The parameters vendor= and product= are no longer available since ca. 3.12 which means that documentation is lagging behind quite some time. Here was the solution: https://bbs.archlinux.org/viewtopic.php?id=175499 insmod usbserial vendor=0x product=0x becomes (first is vendor, second is product) modprobe usbserial echo /sys/bus/usb-serial/drivers/generic/new_id This patch changes the documentation file as needed. Signed-off-by: H. Nikolaus Schaller h...@goldelico.com You are forwarding on a patch from someone else, why didn't you also sign-off on it? Do you not agree with it? I wasn’t involved in patch development I just review it and forward. Yes, I asked Marek to submit this patch (from our local repo). BR, Nikolaus thanks, greg k-h 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 linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi,
Am 26.03.2015 um 06:56 schrieb Pavel Machek pa...@ucw.cz:
Hi!
Main reason is, that I would need to go
through the UART to “communicate with the w2sg0004.
You can always communicate” through the UART. Even without DT. As long as
the connected chip is powered up by any means (could be some
fixed-regulator
or hard wired).
But you don't know how to communicate through the uart.
Maybe we are talking using different assumptions. As long as you have a user
space
gpsd daemon that talks to the gps chip the kernel simply has to
transparently (except
line disciplines) pass the data to the uart.
Forget userspace, some other operating system (or future linux) may
want to put gps handling into the kernel. (To hide differences between
different GPSes).
Because we want the phone to boot knowing I have a bluetooth or I
have a GPS, as it would if it was connected using USB, and not having
user figure out what commands he needs to do to enable reasonable
hardware support (and getting it wrong, because you need to specify
_many_ critical parameters to hciattach).
Yes, this is indeed something I also would like to see for the GTA04 (and
other)
devices.
So the reason is that some kernel driver wants to use the tty/uart to
communicate
directly with the chip. This is very similar to a gpio that some driver
wants to use.
Thus please consider the
/ {
bt {
compatible = vendor,product“;
uart = uart1;
enable = gpio17 34 0;
};
};
Would work, too, but I and everyone knows that subnode is better,
easier solution.
“Everyone” could be wrong and ignorant.
And I thought we are not looking for the easiest solution but the right one.
Especially if we define something that is for other operating systems as well.
About easier: the one given above allows to modify the driver to present e.g.
an iio
interface to user space (and no /dev/tty) *without changing the DT*. Because the
driver code decides which interface it presents. And not where it is a subnode
in DT.
This is the level of abstraction DT nodes should have.
It may be that you did not read my previous argumentation completely.
In short, please see:
http://www.devicetree.org/Device_Tree_Usage#Devices
And check of there is anything that mandates useage of a subnode in this case.
I simply don’t find it.
Rather, although it is also not explicitly excluded, I read hints that it
should *not* be
done the subnode way.
The reason is that it appears to me that the DT hierarchy is intended to
describe
how kernel drivers can *address* different components. Nothing less and nothing
more.
Especially there is no hint that layering in DT has anything to do with data
flow
hierarchies or a “primary” interface as Sebastian calls it.
approach.
And if you want to hide uart1 from the user-space, that should be a property
of the uart1 node (whereever it is defined).
Sorry? That would be one heck of layering violation.
Which layering?
I think you still mix the software/kernel driver/data flow layers with DT
layers.
DT can and must be independent on that.
BR,
Nikolaus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Am 25.03.2015 um 21:53 schrieb Pavel Machek :
> Hi!
>
AFAIK the chip simply starts to emit NMEA records if powered on.
There is no command going over the serial interface to address it
or control it.
>>>
>>> Right, since GPS basically doesn't need any configuration/control.
>>> That’s not true for other UART attached devices, though.
>>
>> Do you have an example? Usually an UART data stream is transparently
>> presented to a /dev/tty - and user-space daemon can configure/control the
>> attached device. In most cases it can mix payload data and control command
>> by some AT command and escape sequences.
>
> Bluetooth H4P protocol is one example.
>
>>> well parent > child is not about power control, but about "primary"
>>> control.
>>
>> Can you clearly and precisely define what “primary” control is? I think
>> two people will have three opinions about that.
>
> This has not be a problem so far...
>
>> For example I would see the w2sg0004 on/off gpio as the primary “control”
>> which makes the light (NMES records) turned on.
>
> ...and I don't think it is a problem now.
>
>>> Main reason is, that I would need to go
>>> through the UART to “communicate" with the w2sg0004.
>>
>> You can always "communicate” through the UART. Even without DT. As long as
>> the connected chip is powered up by any means (could be some fixed-regulator
>> or hard wired).
>
> But you don't know "how" to communicate through the uart.
Maybe we are talking using different assumptions. As long as you have a user
space
gpsd daemon that talks to the gps chip the kernel simply has to transparently
(except
line disciplines) pass the data to the uart.
For that there is no need to describe anything in DT.
>
>> Let me raise the question:
>>
>> Why do we need to describe in the DT (independently of Linux power control
>> structures and drivers!) that the GPS data interface is connected to a
>> specific UART?
>
> Because we want the phone to boot knowing "I have a bluetooth" or "I
> have a GPS", as it would if it was connected using USB, and not having
> user figure out what commands he needs to do to enable reasonable
> hardware support (and getting it wrong, because you need to specify
> _many_ critical parameters to hciattach).
Yes, this is indeed something I also would like to see for the GTA04 (and other)
devices.
So the reason is that some kernel driver wants to use the tty/uart to
communicate
directly with the chip. This is very similar to a gpio that some driver wants
to use.
Thus please consider the
/ {
bt {
compatible = "vendor,product“;
uart = <>;
enable = < 34 0>;
};
};
approach.
And if you want to hide uart1 from the user-space, that should be a property
of the uart1 node (whereever it is defined).
BR,
Nikolaus--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi, Am 25.03.2015 um 21:42 schrieb Pavel Machek : > Hi! > >>> In the case of our GPS, it receives control over the serial connection from >>> the UART, >> >> Ahem - does it? >> >> AFAIK the chip simply starts to emit NMEA records if powered on. There is no >> command going over the serial interface to address it or control it. > > Well _most_ GPSes enable you to control them over the serial > line. (Things like sampling rate, AGPS data upload, …) Yes, I know. But is this something the kernel is/must be aware? And must it be represented by the DT? Or does it have to influence the way the DT is structured? Well, if GPS data is presented through iio, these commands must be handled by some driver. > >>> I think the GPS is “primarily" a uart-attached device. >> >> But not in the same way as an I2C device. >> >> Especially the serial interface is not a bus and not used for signalling and >> power control. It is payload data (only). > > Serial interface looks a lot like a (point-to-point) bus to > me. Similar to SATA, for example. In that sense a gpio looks also a lot like a 1-bit bus... Anyways, there are no subnodes (clients) of a gpio but the <> pattern is used. In other words: a driver that wants to control a gpio asks for a reference of the gpio controller and uses the gpiolib to control it. In the same way, a driver that wants to use an uart could ask for a reference to the tty/uart driver and use some functions to control it (and send commands). So a hypothetical gps-iio driver could set sampling rate etc. And it can also ask the tty/uart: „please register me and notify if some syscall wants you to open() or close() so that I (the driver of the GPS chip) can turn on power of the GPS chip (and only I know how to do that - nobody else has to care)“. I am just playing the Devil's advocate to find out what the really common principle is and how the DT for clients of a serial interface should really be represented in a DT in a way that is agnostic to a specific driver structure, driver functions and user space. And to find out if we need tty/slaves (as proposed in the title of this patch series) at all. Or if there is a better way to describe the relation of the gps chip driver and the tty/uart. BR, Nikolaus-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi, Am 25.03.2015 um 16:21 schrieb Sebastian Reichel : > Hi, > > On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote: >> Am 25.03.2015 um 02:45 schrieb Sebastian Reichel : >>> On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote: >>>> So you propose that the parent->child relationship is “control”? I.e. some >>>> channel which allows to address some bus client (through ) and >>>> control that devices. >>>> >>>> Makes sense. This is how i2c and spi clients are specified. >>>> >>>>> >>>>> In the case of our GPS, it receives control over the serial connection >>>>> from >>>>> the UART, >>>> >>>> Ahem - does it? >>>> >>>> AFAIK the chip simply starts to emit NMEA records if powered on. >>>> There is no command going over the serial interface to address it >>>> or control it. >>> >>> Right, since GPS basically doesn't need any configuration/control. >>> That’s not true for other UART attached devices, though. >> >> Do you have an example? Usually an UART data stream is transparently >> presented to a /dev/tty - and user-space daemon can configure/control the >> attached device. In most cases it can mix payload data and control command >> by some AT command and escape sequences. > > Yes, but the configuration is minimal. Anyways as you said there > *is* some kind of control happening over the UART. Control is happening on a higher network stack level than UART. It control is done through AT commands. > >>>>> also receives control via a GPIO to the on/off pin, and also needs >>>>> a regulator to power the antenna. >>>>> >>>>> So should the parent be the uart, the on/off GPIO, or the regulator? >>>>> >>>>> I would much rather there wasn't a parent, and that each of these were >>>>> listed >>>>> as ad-hoc attribute assignments. But device-tree says there must be a >>>>> parent >>>>> (where possible), and the parent is the thing that is “primarily" in >>>>> control. >>>> >>>> Well, IMHO the “parent” could also be the root. Representing the >>>> whole board. >>>> >>>> Nevertheless, I doubt your rule that “ability to control” defines >>>> the parent>child relation (see below). >>>> >>>>> >>>>> I think the GPS is “primarily" a uart-attached device. >>>> >>>> But not in the same way as an I2C device. >>>> >>>> Especially the serial interface is not a bus and not used for >>>> signalling and power control. It is payload data (only). >>> >>> Actually many I2C devices are also powered on/off via a GPIO and >>> even use additional GPIOs for sending interrupts. Nevertheless they >>> are normally identified as an I2C device. >> >> Because I2C is a bus that can address multiple clients and gpio isn’t >> a bus and a point-to-point connection. >> >> But IMHO it is not because they (can) send payload data over i2c. > > From my POV it's not because I2C is a bus, but because the primary > function is happening via I2C (e.g. configuring sensor, gettings its > data). The GPIOs are only needed to compensate some I2C shortcomings > (missing irq feature in I2C) or reduce the complexity of the client > (power GPIO). The actual system interaction with the I2C chip is > going via I2C, though. Yes, but this is in my new understanding irrelevant for proper DT description. > >>> Also for non-GPS device the serial connection is used for >>> controlling and configuring the device. >> >> This assumes that “controls a device” is the criterion for making a device >> a subnode. I doubt that. > > For me the criterion always was "accessing the device's > registers/configuration/data" from the system's point of view (so > your video port does not count, since it models a connection between > two components without system interaction). > >>>>> So I propose a device-node which describes the GPS, which is a child of >>>>> the >>>>> UART, and explicitly identifies the GPIO it uses to power on/off, the >>>>> regulator it uses to power the antenna, and how it receives "on or off" >>>>> status indications from the GPS. >>>> >>>> The more I think about that, y
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi, Am 25.03.2015 um 02:45 schrieb Sebastian Reichel : > Hi, > > On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote: >> So you propose that the parent->child relationship is “control”? I.e. some >> channel which allows to address some bus client (through ) and >> control that devices. >> >> Makes sense. This is how i2c and spi clients are specified. >> >>> >>> In the case of our GPS, it receives control over the serial connection from >>> the UART, >> >> Ahem - does it? >> >> AFAIK the chip simply starts to emit NMEA records if powered on. >> There is no command going over the serial interface to address it >> or control it. > > Right, since GPS basically doesn't need any configuration/control. > That’s not true for other UART attached devices, though. Do you have an example? Usually an UART data stream is transparently presented to a /dev/tty - and user-space daemon can configure/control the attached device. In most cases it can mix payload data and control command by some AT command and escape sequences. > >>> also receives control via a GPIO to the on/off pin, and also needs >>> a regulator to power the antenna. >>> >>> So should the parent be the uart, the on/off GPIO, or the regulator? >>> >>> I would much rather there wasn't a parent, and that each of these were >>> listed >>> as ad-hoc attribute assignments. But device-tree says there must be a >>> parent >>> (where possible), and the parent is the thing that is “primarily" in >>> control. >> >> Well, IMHO the “parent” could also be the root. Representing the >> whole board. >> >> Nevertheless, I doubt your rule that “ability to control” defines >> the parent>child relation (see below). >> >>> >>> I think the GPS is “primarily" a uart-attached device. >> >> But not in the same way as an I2C device. >> >> Especially the serial interface is not a bus and not used for >> signalling and power control. It is payload data (only). > > Actually many I2C devices are also powered on/off via a GPIO and > even use additional GPIOs for sending interrupts. Nevertheless they > are normally identified as an I2C device. Because I2C is a bus that can address multiple clients and gpio isn’t a bus and a point-to-point connection. But IMHO it is not because they (can) send payload data over i2c. > > Also for non-GPS device the serial connection is used for > controlling and configuring the device. This assumes that “controls a device” is the criterion for making a device a subnode. I doubt that. > >>> So I propose a device-node which describes the GPS, which is a child of the >>> UART, and explicitly identifies the GPIO it uses to power on/off, the >>> regulator it uses to power the antenna, and how it receives "on or off" >>> status indications from the GPS. >> >> The more I think about that, you have given good arguments *not* >> to use the parent->child relationship for the UART interface of >> the GPS. >> >> Let me give another example. The 3G Modem has 3 (or 4) interfaces: >> 1. an USB-Interface for AT signalling and payload >> 2. some GPIOs for power control. >> 3. a PCM interface for digital voice. >> 4. it might also have a serial interface as alternate AT command and (GPRS >>low speed) payload. >> >> So which one is the most prominent or most important to make it a child of? >> >> If you use “control” you must make it a child of the USB phy and the serial >> interface >> which requires multiple inheritance… >> >> So I am not sure at all. None is IMHO prominent and unique enough to make it >> a parent>child relation. >> >> Threrefore, I would be happy to see it as multiple children of /. For >> example a >> MFD with subnodes. > > This scenario has already been seen before and can happen for > non-UART based devices (e.g. SPI + I2C). So far the decision was to > postpone the discussion about this kind of devices until one of them > appears. > >>> It is arguable that the "antenna" should be treated as a separate device - a >>> child of the GPS - which controls the regulator and also provides a 'extcon' >>> which reports whether an external GPS antenna is attached, or whether the >>> internal on is in use. I haven't made the time to properly explore that >>> issue yet. >> >> If you assume that parent>child relationship is about control (only). But if >>
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi, Am 25.03.2015 um 02:45 schrieb Sebastian Reichel s...@kernel.org: Hi, On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote: So you propose that the parent-child relationship is “control”? I.e. some channel which allows to address some bus client (through reg) and control that devices. Makes sense. This is how i2c and spi clients are specified. In the case of our GPS, it receives control over the serial connection from the UART, Ahem - does it? AFAIK the chip simply starts to emit NMEA records if powered on. There is no command going over the serial interface to address it or control it. Right, since GPS basically doesn't need any configuration/control. That’s not true for other UART attached devices, though. Do you have an example? Usually an UART data stream is transparently presented to a /dev/tty - and user-space daemon can configure/control the attached device. In most cases it can mix payload data and control command by some AT command and escape sequences. also receives control via a GPIO to the on/off pin, and also needs a regulator to power the antenna. So should the parent be the uart, the on/off GPIO, or the regulator? I would much rather there wasn't a parent, and that each of these were listed as ad-hoc attribute assignments. But device-tree says there must be a parent (where possible), and the parent is the thing that is “primarily in control. Well, IMHO the “parent” could also be the root. Representing the whole board. Nevertheless, I doubt your rule that “ability to control” defines the parentchild relation (see below). I think the GPS is “primarily a uart-attached device. But not in the same way as an I2C device. Especially the serial interface is not a bus and not used for signalling and power control. It is payload data (only). Actually many I2C devices are also powered on/off via a GPIO and even use additional GPIOs for sending interrupts. Nevertheless they are normally identified as an I2C device. Because I2C is a bus that can address multiple clients and gpio isn’t a bus and a point-to-point connection. But IMHO it is not because they (can) send payload data over i2c. Also for non-GPS device the serial connection is used for controlling and configuring the device. This assumes that “controls a device” is the criterion for making a device a subnode. I doubt that. So I propose a device-node which describes the GPS, which is a child of the UART, and explicitly identifies the GPIO it uses to power on/off, the regulator it uses to power the antenna, and how it receives on or off status indications from the GPS. The more I think about that, you have given good arguments *not* to use the parent-child relationship for the UART interface of the GPS. Let me give another example. The 3G Modem has 3 (or 4) interfaces: 1. an USB-Interface for AT signalling and payload 2. some GPIOs for power control. 3. a PCM interface for digital voice. 4. it might also have a serial interface as alternate AT command and (GPRS low speed) payload. So which one is the most prominent or most important to make it a child of? If you use “control” you must make it a child of the USB phy and the serial interface which requires multiple inheritance… So I am not sure at all. None is IMHO prominent and unique enough to make it a parentchild relation. Threrefore, I would be happy to see it as multiple children of /. For example a MFD with subnodes. This scenario has already been seen before and can happen for non-UART based devices (e.g. SPI + I2C). So far the decision was to postpone the discussion about this kind of devices until one of them appears. It is arguable that the antenna should be treated as a separate device - a child of the GPS - which controls the regulator and also provides a 'extcon' which reports whether an external GPS antenna is attached, or whether the internal on is in use. I haven't made the time to properly explore that issue yet. If you assume that parentchild relationship is about control (only). But if it is about data flow, there is a different concept in DT. For example the CSI/DSI (OMAP DSS) use the “port” concept. Yes, this is about data not going to the cpu / system memory. Really? The frame buffer data is in system memory and gets to the panel. Or a camera image ends up in system memory. This means that indeed parentchild is used for control, e.g. I2C or SPI to tell the panel controller to switch on. well parent child is not about power control, but about primary control. Can you clearly and precisely define what “primary” control is? I think two people will have three opinions about that. For example I would see the w2sg0004 on/off gpio as the primary “control” which makes the light (NMES records) turned on. Therefore we should make it the subnode of some gpio-controller, shouldn’t we? Some I2C/SPI
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi, Am 25.03.2015 um 16:21 schrieb Sebastian Reichel s...@kernel.org: Hi, On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote: Am 25.03.2015 um 02:45 schrieb Sebastian Reichel s...@kernel.org: On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote: So you propose that the parent-child relationship is “control”? I.e. some channel which allows to address some bus client (through reg) and control that devices. Makes sense. This is how i2c and spi clients are specified. In the case of our GPS, it receives control over the serial connection from the UART, Ahem - does it? AFAIK the chip simply starts to emit NMEA records if powered on. There is no command going over the serial interface to address it or control it. Right, since GPS basically doesn't need any configuration/control. That’s not true for other UART attached devices, though. Do you have an example? Usually an UART data stream is transparently presented to a /dev/tty - and user-space daemon can configure/control the attached device. In most cases it can mix payload data and control command by some AT command and escape sequences. Yes, but the configuration is minimal. Anyways as you said there *is* some kind of control happening over the UART. Control is happening on a higher network stack level than UART. It control is done through AT commands. also receives control via a GPIO to the on/off pin, and also needs a regulator to power the antenna. So should the parent be the uart, the on/off GPIO, or the regulator? I would much rather there wasn't a parent, and that each of these were listed as ad-hoc attribute assignments. But device-tree says there must be a parent (where possible), and the parent is the thing that is “primarily in control. Well, IMHO the “parent” could also be the root. Representing the whole board. Nevertheless, I doubt your rule that “ability to control” defines the parentchild relation (see below). I think the GPS is “primarily a uart-attached device. But not in the same way as an I2C device. Especially the serial interface is not a bus and not used for signalling and power control. It is payload data (only). Actually many I2C devices are also powered on/off via a GPIO and even use additional GPIOs for sending interrupts. Nevertheless they are normally identified as an I2C device. Because I2C is a bus that can address multiple clients and gpio isn’t a bus and a point-to-point connection. But IMHO it is not because they (can) send payload data over i2c. From my POV it's not because I2C is a bus, but because the primary function is happening via I2C (e.g. configuring sensor, gettings its data). The GPIOs are only needed to compensate some I2C shortcomings (missing irq feature in I2C) or reduce the complexity of the client (power GPIO). The actual system interaction with the I2C chip is going via I2C, though. Yes, but this is in my new understanding irrelevant for proper DT description. Also for non-GPS device the serial connection is used for controlling and configuring the device. This assumes that “controls a device” is the criterion for making a device a subnode. I doubt that. For me the criterion always was accessing the device's registers/configuration/data from the system's point of view (so your video port does not count, since it models a connection between two components without system interaction). So I propose a device-node which describes the GPS, which is a child of the UART, and explicitly identifies the GPIO it uses to power on/off, the regulator it uses to power the antenna, and how it receives on or off status indications from the GPS. The more I think about that, you have given good arguments *not* to use the parent-child relationship for the UART interface of the GPS. Let me give another example. The 3G Modem has 3 (or 4) interfaces: 1. an USB-Interface for AT signalling and payload 2. some GPIOs for power control. 3. a PCM interface for digital voice. 4. it might also have a serial interface as alternate AT command and (GPRS low speed) payload. So which one is the most prominent or most important to make it a child of? If you use “control” you must make it a child of the USB phy and the serial interface which requires multiple inheritance… So I am not sure at all. None is IMHO prominent and unique enough to make it a parentchild relation. Threrefore, I would be happy to see it as multiple children of /. For example a MFD with subnodes. This scenario has already been seen before and can happen for non-UART based devices (e.g. SPI + I2C). So far the decision was to postpone the discussion about this kind of devices until one of them appears. It is arguable that the antenna should be treated as a separate device - a child of the GPS - which controls the regulator and also provides a 'extcon' which
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi, Am 25.03.2015 um 21:42 schrieb Pavel Machek pa...@ucw.cz: Hi! In the case of our GPS, it receives control over the serial connection from the UART, Ahem - does it? AFAIK the chip simply starts to emit NMEA records if powered on. There is no command going over the serial interface to address it or control it. Well _most_ GPSes enable you to control them over the serial line. (Things like sampling rate, AGPS data upload, …) Yes, I know. But is this something the kernel is/must be aware? And must it be represented by the DT? Or does it have to influence the way the DT is structured? Well, if GPS data is presented through iio, these commands must be handled by some driver. I think the GPS is “primarily a uart-attached device. But not in the same way as an I2C device. Especially the serial interface is not a bus and not used for signalling and power control. It is payload data (only). Serial interface looks a lot like a (point-to-point) bus to me. Similar to SATA, for example. In that sense a gpio looks also a lot like a 1-bit bus... Anyways, there are no subnodes (clients) of a gpio but the gpiocontroller pattern is used. In other words: a driver that wants to control a gpio asks for a reference of the gpio controller and uses the gpiolib to control it. In the same way, a driver that wants to use an uart could ask for a reference to the tty/uart driver and use some functions to control it (and send commands). So a hypothetical gps-iio driver could set sampling rate etc. And it can also ask the tty/uart: „please register me and notify if some syscall wants you to open() or close() so that I (the driver of the GPS chip) can turn on power of the GPS chip (and only I know how to do that - nobody else has to care)“. I am just playing the Devil's advocate to find out what the really common principle is and how the DT for clients of a serial interface should really be represented in a DT in a way that is agnostic to a specific driver structure, driver functions and user space. And to find out if we need tty/slaves (as proposed in the title of this patch series) at all. Or if there is a better way to describe the relation of the gps chip driver and the tty/uart. BR, Nikolaus-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Am 25.03.2015 um 21:53 schrieb Pavel Machek pa...@ucw.cz:
Hi!
AFAIK the chip simply starts to emit NMEA records if powered on.
There is no command going over the serial interface to address it
or control it.
Right, since GPS basically doesn't need any configuration/control.
That’s not true for other UART attached devices, though.
Do you have an example? Usually an UART data stream is transparently
presented to a /dev/tty - and user-space daemon can configure/control the
attached device. In most cases it can mix payload data and control command
by some AT command and escape sequences.
Bluetooth H4P protocol is one example.
well parent child is not about power control, but about primary
control.
Can you clearly and precisely define what “primary” control is? I think
two people will have three opinions about that.
This has not be a problem so far...
For example I would see the w2sg0004 on/off gpio as the primary “control”
which makes the light (NMES records) turned on.
...and I don't think it is a problem now.
Main reason is, that I would need to go
through the UART to “communicate with the w2sg0004.
You can always communicate” through the UART. Even without DT. As long as
the connected chip is powered up by any means (could be some fixed-regulator
or hard wired).
But you don't know how to communicate through the uart.
Maybe we are talking using different assumptions. As long as you have a user
space
gpsd daemon that talks to the gps chip the kernel simply has to transparently
(except
line disciplines) pass the data to the uart.
For that there is no need to describe anything in DT.
Let me raise the question:
Why do we need to describe in the DT (independently of Linux power control
structures and drivers!) that the GPS data interface is connected to a
specific UART?
Because we want the phone to boot knowing I have a bluetooth or I
have a GPS, as it would if it was connected using USB, and not having
user figure out what commands he needs to do to enable reasonable
hardware support (and getting it wrong, because you need to specify
_many_ critical parameters to hciattach).
Yes, this is indeed something I also would like to see for the GTA04 (and other)
devices.
So the reason is that some kernel driver wants to use the tty/uart to
communicate
directly with the chip. This is very similar to a gpio that some driver wants
to use.
Thus please consider the
/ {
bt {
compatible = vendor,product“;
uart = uart1;
enable = gpio17 34 0;
};
};
approach.
And if you want to hide uart1 from the user-space, that should be a property
of the uart1 node (whereever it is defined).
BR,
Nikolaus--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi,
Am 21.03.2015 um 00:31 schrieb NeilBrown :
> On Fri, 20 Mar 2015 10:34:18 +0100 "Dr. H. Nikolaus Schaller"
> wrote:
>
>>
>> Am 20.03.2015 um 09:54 schrieb NeilBrown :
>
>>> There needs to be one device-node for each device, and that device-node
>>> needs
>>> to be a child of the device-node for the device which is the primary
>>> connection to the child device.
>>
>> Then please explain to me nodes like
>>
>> / {
>> compatible = "ti,omap3-gta04", "ti,omap36xx", "ti,omap3";
>>
>> cpus {
>> cpu@0 {
>> cpu0-supply = <>;
>> };
>> };
>>
>> According to the rule you apply here it should be something like
>>
>> cpu@0 {
>> regulator {
>> …
>> }
>>
>>
>
> This exactly highlight one of the big problems with device tree as I see it.
>
> Each device can potentially have relationships with a number of other
> devices, for the supply of power, reset signalling, interrupt handled, data
> transfer, command transfer etc etc etc.
Yes. The network is a mesh.
>
> devicetree provides two ways to indicated a relationship between devices.
> One way is a parent/child arrangement. The other way is ad-hoc
> attribute = <>
> assignments.
Yes.
>
> Each device can only have one parent, but can have multiple arbitrary
> assignments.
>
> I would much rather that the parent/child relationship didn't exist at all.
> Each device should stand alone, and list all relationships explicitly. But
> that is not the way devicetree works, and we need to live with that.
Is it not how the device tree works or how we use it? Or how you think it
should better be?
What stops us from using it in arbitrary assignments like clocks and
regulators?
GPIOs are also a nice example: you just specify the gpio controller
and the gpio number to use it. There is no parent/child connection.
Why for tty / serial and serial consumers but not for GPIOs?
I have tried to find out the rules when parent>child is used (see below).
>
> So we need a clear understanding of what the 'parent' of a given device
> should be.
> I don't know what the specifications say, if anything, but what I see is that
> the parent is in practive a device which can ‘address' the child.
I think this holds only for “bus” devices - where it is really a good and
standard way of structuring the bus and it’s masters/slaves. One child
node per client.
> i.e.
> control signalling is the key parent->child relationship.
> This is consistent with the fact that many device nodes have a
> reg=
> attribute which gives the address of the node as seen by it's parent.
>
> Given that understanding, a regulator must be a child of the device which can
> control it - which can turn it on or off. Not a child of the device which
> receives power from it.
So you propose that the parent->child relationship is “control”? I.e. some
channel which allows to address some bus client (through ) and
control that devices.
Makes sense. This is how i2c and spi clients are specified.
>
> In the case of our GPS, it receives control over the serial connection from
> the UART,
Ahem - does it?
AFAIK the chip simply starts to emit NMEA records if powered on. There is no
command going over the serial interface to address it or control it.
> also receives control via a GPIO to the on/off pin, and also needs
> a regulator to power the antenna.
>
> So should the parent be the uart, the on/off GPIO, or the regulator?
>
> I would much rather there wasn't a parent, and that each of these were listed
> as ad-hoc attribute assignments. But device-tree says there must be a parent
> (where possible), and the parent is the thing that is “primarily" in control.
Well, IMHO the “parent” could also be the root. Representing the whole board.
Nevertheless, I doubt your rule that “ability to control” defines the
parent>child
relation (see below).
>
> I think the GPS is “primarily" a uart-attached device.
But not in the same way as an I2C device.
Especially the serial interface is not a bus and not used for signalling and
power control. It is payload data (only).
> So I propose a device-node which describes the GPS, which is a child of the
> UART, and explicitly identifies the GPIO it uses to power on/off, the
> regulator it uses to power the antenna, and how it receives "on or off"
> status indications from the GPS.
The more I think about that, you have given good arguments *not* to use the
parent->child relationship for the UART interface of the GPS.
Let me g
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Hi,
Am 21.03.2015 um 00:31 schrieb NeilBrown ne...@suse.de:
On Fri, 20 Mar 2015 10:34:18 +0100 Dr. H. Nikolaus Schaller
h...@goldelico.com wrote:
Am 20.03.2015 um 09:54 schrieb NeilBrown ne...@suse.de:
There needs to be one device-node for each device, and that device-node
needs
to be a child of the device-node for the device which is the primary
connection to the child device.
Then please explain to me nodes like
/ {
compatible = ti,omap3-gta04, ti,omap36xx, ti,omap3;
cpus {
cpu@0 {
cpu0-supply = vcc;
};
};
According to the rule you apply here it should be something like
cpu@0 {
regulator {
…
}
This exactly highlight one of the big problems with device tree as I see it.
Each device can potentially have relationships with a number of other
devices, for the supply of power, reset signalling, interrupt handled, data
transfer, command transfer etc etc etc.
Yes. The network is a mesh.
devicetree provides two ways to indicated a relationship between devices.
One way is a parent/child arrangement. The other way is ad-hoc
attribute = devicename
assignments.
Yes.
Each device can only have one parent, but can have multiple arbitrary
assignments.
I would much rather that the parent/child relationship didn't exist at all.
Each device should stand alone, and list all relationships explicitly. But
that is not the way devicetree works, and we need to live with that.
Is it not how the device tree works or how we use it? Or how you think it
should better be?
What stops us from using it in arbitrary assignments like clocks and
regulators?
GPIOs are also a nice example: you just specify the gpio controller
and the gpio number to use it. There is no parent/child connection.
Why for tty / serial and serial consumers but not for GPIOs?
I have tried to find out the rules when parentchild is used (see below).
So we need a clear understanding of what the 'parent' of a given device
should be.
I don't know what the specifications say, if anything, but what I see is that
the parent is in practive a device which can ‘address' the child.
I think this holds only for “bus” devices - where it is really a good and
standard way of structuring the bus and it’s masters/slaves. One child
node per client.
i.e.
control signalling is the key parent-child relationship.
This is consistent with the fact that many device nodes have a
reg=xxx
attribute which gives the address of the node as seen by it's parent.
Given that understanding, a regulator must be a child of the device which can
control it - which can turn it on or off. Not a child of the device which
receives power from it.
So you propose that the parent-child relationship is “control”? I.e. some
channel which allows to address some bus client (through reg) and
control that devices.
Makes sense. This is how i2c and spi clients are specified.
In the case of our GPS, it receives control over the serial connection from
the UART,
Ahem - does it?
AFAIK the chip simply starts to emit NMEA records if powered on. There is no
command going over the serial interface to address it or control it.
also receives control via a GPIO to the on/off pin, and also needs
a regulator to power the antenna.
So should the parent be the uart, the on/off GPIO, or the regulator?
I would much rather there wasn't a parent, and that each of these were listed
as ad-hoc attribute assignments. But device-tree says there must be a parent
(where possible), and the parent is the thing that is “primarily in control.
Well, IMHO the “parent” could also be the root. Representing the whole board.
Nevertheless, I doubt your rule that “ability to control” defines the
parentchild
relation (see below).
I think the GPS is “primarily a uart-attached device.
But not in the same way as an I2C device.
Especially the serial interface is not a bus and not used for signalling and
power control. It is payload data (only).
So I propose a device-node which describes the GPS, which is a child of the
UART, and explicitly identifies the GPIO it uses to power on/off, the
regulator it uses to power the antenna, and how it receives on or off
status indications from the GPS.
The more I think about that, you have given good arguments *not* to use the
parent-child relationship for the UART interface of the GPS.
Let me give another example. The 3G Modem has 3 (or 4) interfaces:
1. an USB-Interface for AT signalling and payload
2. some GPIOs for power control.
3. a PCM interface for digital voice.
4. it might also have a serial interface as alternate AT command and (GPRS
low speed) payload.
So which one is the most prominent or most important to make it a child of?
If you use “control” you must make it a child of the USB phy and the serial
interface
which requires multiple inheritance
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 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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
Am 20.03.2015 um 09:54 schrieb NeilBrown :
> On Fri, 20 Mar 2015 08:54:38 +0100 "Dr. H. Nikolaus Schaller"
> wrote:
>
>>
>> Am 18.03.2015 um 06:58 schrieb NeilBrown :
>>
>>> If a platform has a particular device permanently attached to a UART,
>>> there may be out-of-band signaling necessary to power the device
>>> on and off.
>>>
>>> This driver controls that signalling for a number of different devices.
>>> It can
>>> - enable/disable a regulator
>>> - toggle a GPIO
>>> - register an 'rfkill' which can force the device to be off.
>>>
>>> When the rfkill is absent or unblocked, the device will be on when the
>>> associated tty device is open, and closed otherwise.
>>>
>>> Signed-off-by: NeilBrown
>>> ---
>>> .../bindings/tty_slave/wi2wi,w2cbw003.txt | 19 +
>>> .../bindings/tty_slave/wi2wi,w2sg0004.txt | 37 +
>>> .../devicetree/bindings/vendor-prefixes.txt|1
>>> drivers/tty/slave/Kconfig | 14 +
>>> drivers/tty/slave/Makefile |2
>>> drivers/tty/slave/serial-power-manager.c | 510
>>>
>>> 6 files changed, 583 insertions(+)
>>> 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/serial-power-manager.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
>>> b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
>>> new file mode 100644
>>> index ..cfe6ee5e01e9
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
>>> @@ -0,0 +1,19 @@
>>> +wi2wi bluetooth module
>>> +
>>> +This is accessed via a serial port and is largely controlled via that
>>> +link. Extra configuration is needed to enable power on/off
>>> +
>>> +Required properties:
>>> +- compatible: "wi2wi,w2cbw003"
>>> +- vdd-supply: regulator used to power the device.
>>> +
>>> +The node for this device must be the child of a UART.
>>> +
>>> +Example:
>>> +
>>> + {
>>> + bluetooth {
>>> + compatible = "wi2wi,w2cbw003";
>>> + vdd-supply = <>;
>>> + };
>>> +};
>>
>> Wouldn’t it be easier to simply write
>>
>> {
>> vdd-suppy = <>;
>> }
>
> Easier to write: certainly.
> Easier to justify? No.
I just justified.
> Easier to get merged upstream? Definitely not.
Are you the maintainer?
> After all, the uart itself doesn't require a power supply.
> It is the device connected to the uart which requires the power supply.
Yes.
>
>
>>
>>> diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
>>> b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
>>> new file mode 100644
>>> index ..fdc52cf56533
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
>>> @@ -0,0 +1,37 @@
>>> +wi2wi GPS device
>>> +
>>> +This is accessed via a serial port and is largely controlled via that
>>> +link. Extra configuration is needed to enable power on/off
>>> +
>>> +Required properties:
>>> +- compatible: "wi2wi,w2sg0004"
>>> +- gpios: gpios used to toggle 'on/off' pin
>>> +- interrupts: interrupt generated by RX pin when device
>>> + should be off
>>> +
>>> +Optional properties:
>>> +- vdd-supply: regulator used to power antenna
>>> +- pinctrl: "default", "off"
>>> + if "off" setting is provided it is imposed when device should
>>> + be off. This can route the RX pin to a GPIO interrupt.
>>> +
>>> +The w2sg0004 uses a pin-toggle both to power-on and to
>>> +power-off, so the driver needs to detect what state it is in.
>>> +It does this by detecting characters on the RX line.
>>> +When it should be off, these can optionally be detected by a GPIO.
>>> +
>>> +The node for this device must be the child of a UART.
>>> +
>>> +Example:
>>> + {
>>> + gps {
>>> +
