* Re: [RFC PATCH 0/2] serial: 8250_dw: IO space + polling mode support
From: John Garry @ 2018-04-12 16:31 UTC (permalink / raw)
To: Andy Shevchenko
Cc: gregkh, jslaby, p.zabel, heiko, ed.blake, jhogan, linux-serial,
linux-kernel, linuxarm
In-Reply-To: <98039a90-cbf2-6d76-bdb5-56c8e83f6470@huawei.com>
On 26/02/2018 15:07, John Garry wrote:
> On 26/02/2018 15:02, Andy Shevchenko wrote:
>> On Mon, 2018-02-26 at 13:15 +0000, John Garry wrote:
>>> On 26/02/2018 12:27, Andy Shevchenko wrote:
>>>> On Mon, 2018-02-26 at 14:21 +0200, Andy Shevchenko wrote:
>>>>> On Mon, 2018-02-26 at 11:56 +0000, John Garry wrote:
>>>>
>>>>
>>>>>> Device (LPC0.CON0) {
>>>>>> Name (_HID, "HISI1031")
>>>>>> // Name (_CID, "PNP0501") // cannot support PNP
>>>>
>>>>
>>>> One more question. What is the problem with this CID? Do you have a
>>>> race
>>>> condition in enumeration?
>>>>
>>>
>>> Hi Andy,
>>>
>>> Not sure if race condition exactly. I tried enabling this CID and a
>>> pnp
>>> device is created in pnpacpi_add_device_handler(), while we have
>>> already
>>> marked the corresponding acpi_device to skip enumeration in ACPI scan
>>> handler (by flagging it as a serial bus slave).
>>
>> Is that code already in upstream?
>
> No, not yet.
>
>>
>> If no, please, Cc next version to me and possible Mika.
>
> Of course. I should be sending it later today.
>
Hi Andy,
A while ago we discussed on this thread the possibility of adding
generic 8250 IO space platform driver support for ACPI FW.
In this discussion I mentioned that we require specifically platform
device support, and not PNP device support, as this is how we enumerate
the devices in the host controller driver. I think you're familiar with
this driver - here is the thread posting for reference:
https://lkml.org/lkml/2018/3/6/230
I would say that there were 2 main takeaway points:
a. for 8250-compatible UART, we should use a PNP driver for ACPI FW
b. you prefered us to change the host driver to use an ACPI handler approach
For b., I was not keen as we already did try the handler in the ACPI
core code, but this was not so welcome. Reasoning here:
https://lkml.org/lkml/2018/2/14/532
I did also say that I would prefer not to change approach after a very
long upstream effort, with no clear end in sight.
However do you have an idea on creating a PNP device in a.? That is,
enumerate (create) a 8250 PNP device.
If you look at the least driver here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/bus/hisi_lpc.c
We could have this working with a change in the ACPI probe code, like in
this code snippet:
list_for_each_entry(child, &adev->children, node) {
struct resource_entry *rentry;
LIST_HEAD(resource_list);
int rc;
if (!acpi_is_pnp_device(child))
continue;
acpi_dev_get_resources(child, &resource_list, NULL, NULL);
list_for_each_entry(rentry, &resource_list, node) {
struct resource *res = rentry->res;
if (res->flags | IORESOURCE_IO)
hisi_lpc_acpi_xlat_io_res(child, adev, res); /* bad */
}
rc = pnpacpi_add_device(child);
if (rc)
return rc;
}
Obviously this is not sound as we should not modify the child
acpi_device resources.
Alternatively, as another approach, I could copy the relevant code
pnpacpi_add_device() verbatim into this above code, and xlat the
resource of the PNP device, but it's not good to copy the code like.
Any other ideas?
All the best,
John
>>
> All the best,
> John
^ permalink raw reply
* [PATCH 4.9 263/310] tty: n_gsm: Allow ADM response in addition to UA for control dlci
From: Greg Kroah-Hartman @ 2018-04-11 18:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, linux-serial, Alan Cox, Jiri Prchal,
Jiri Slaby, Marcel Partap, Michael Scott, Peter Hurley,
Russ Gorby, Sascha Hauer, Sebastian Reichel, Tony Lindgren,
Sasha Levin
In-Reply-To: <20180411183622.305902791@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Lindgren <tony@atomide.com>
[ Upstream commit ea3d8465ab9b3e01be329ac5195970a84bef76c5 ]
Some devices have the control dlci stay in ADM mode instead of the UA
mode. This can seen at least on droid 4 when trying to open the ts
27.010 mux port. Enabling n_gsm debug mode shows the control dlci
always respond with DM to SABM instead of UA:
# modprobe n_gsm debug=0xff
# ldattach -d GSM0710 /dev/ttyS0 &
gsmld_output: 00000000: f9 03 3f 01 1c f9
--> 0) C: SABM(P)
gsmld_receive: 00000000: f9 03 1f 01 36 f9
<-- 0) C: DM(P)
...
$ minicom -D /dev/gsmtty1
minicom: cannot open /dev/gsmtty1: No error information
$ strace minicom -D /dev/gsmtty1
...
open("/dev/gsmtty1", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = -1 EL2HLT
Note that this is different issue from other n_gsm -EL2HLT issues such
as timeouts when the control dlci does not respond at all.
The ADM mode seems to be a quite common according to "RF Wireless World"
article "GSM Issue-UE sends SABM and gets a DM response instead of
UA response":
This issue is most commonly observed in GSM networks where in UE sends
SABM and expects network to send UA response but it ends up receiving
DM response from the network. SABM stands for Set asynchronous balanced
mode, UA stands for Unnumbered Acknowledge and DA stands for
Disconnected Mode.
An RLP entity can be in one of two modes:
- Asynchronous Balanced Mode (ABM)
- Asynchronous Disconnected Mode (ADM)
Currently Linux kernel closes the control dlci after several retries
in gsm_dlci_t1() on DM. This causes n_gsm /dev/gsmtty ports to produce
error code -EL2HLT when trying to open them as the closing of control
dlci has already set gsm->dead.
Let's fix the issue by allowing control dlci stay in ADM mode after the
retries so the /dev/gsmtty ports can be opened and used. It seems that
it might take several attempts to get any response from the control
dlci, so it's best to allow ADM mode only after the SABM retries are
done.
Note that for droid 4 additional patches are needed to mux the ttyS0
pins and to toggle RTS gpio_149 to wake up the mdm6600 modem are also
needed to use n_gsm. And the mdm6600 modem needs to be powered on.
Cc: linux-serial@vger.kernel.org
Cc: Alan Cox <alan@llwyncelyn.cymru>
Cc: Jiri Prchal <jiri.prchal@aksignal.cz>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Michael Scott <michael.scott@linaro.org>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Russ Gorby <russ.gorby@intel.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/n_gsm.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -1467,6 +1467,10 @@ static void gsm_dlci_open(struct gsm_dlc
* in which case an opening port goes back to closed and a closing port
* is simply put into closed state (any further frames from the other
* end will get a DM response)
+ *
+ * Some control dlci can stay in ADM mode with other dlci working just
+ * fine. In that case we can just keep the control dlci open after the
+ * DLCI_OPENING retries time out.
*/
static void gsm_dlci_t1(unsigned long data)
@@ -1480,8 +1484,15 @@ static void gsm_dlci_t1(unsigned long da
if (dlci->retries) {
gsm_command(dlci->gsm, dlci->addr, SABM|PF);
mod_timer(&dlci->t1, jiffies + gsm->t1 * HZ / 100);
- } else
+ } else if (!dlci->addr && gsm->control == (DM | PF)) {
+ if (debug & 8)
+ pr_info("DLCI %d opening in ADM mode.\n",
+ dlci->addr);
+ gsm_dlci_open(dlci);
+ } else {
gsm_dlci_close(dlci);
+ }
+
break;
case DLCI_CLOSING:
dlci->retries--;
@@ -1499,8 +1510,8 @@ static void gsm_dlci_t1(unsigned long da
* @dlci: DLCI to open
*
* Commence opening a DLCI from the Linux side. We issue SABM messages
- * to the modem which should then reply with a UA, at which point we
- * will move into open state. Opening is done asynchronously with retry
+ * to the modem which should then reply with a UA or ADM, at which point
+ * we will move into open state. Opening is done asynchronously with retry
* running off timers and the responses.
*/
^ permalink raw reply
* [PATCH 4.4 155/190] tty: n_gsm: Allow ADM response in addition to UA for control dlci
From: Greg Kroah-Hartman @ 2018-04-11 18:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, linux-serial, Alan Cox, Jiri Prchal,
Jiri Slaby, Marcel Partap, Michael Scott, Peter Hurley,
Russ Gorby, Sascha Hauer, Sebastian Reichel, Tony Lindgren,
Sasha Levin
In-Reply-To: <20180411183550.114495991@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Lindgren <tony@atomide.com>
[ Upstream commit ea3d8465ab9b3e01be329ac5195970a84bef76c5 ]
Some devices have the control dlci stay in ADM mode instead of the UA
mode. This can seen at least on droid 4 when trying to open the ts
27.010 mux port. Enabling n_gsm debug mode shows the control dlci
always respond with DM to SABM instead of UA:
# modprobe n_gsm debug=0xff
# ldattach -d GSM0710 /dev/ttyS0 &
gsmld_output: 00000000: f9 03 3f 01 1c f9
--> 0) C: SABM(P)
gsmld_receive: 00000000: f9 03 1f 01 36 f9
<-- 0) C: DM(P)
...
$ minicom -D /dev/gsmtty1
minicom: cannot open /dev/gsmtty1: No error information
$ strace minicom -D /dev/gsmtty1
...
open("/dev/gsmtty1", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = -1 EL2HLT
Note that this is different issue from other n_gsm -EL2HLT issues such
as timeouts when the control dlci does not respond at all.
The ADM mode seems to be a quite common according to "RF Wireless World"
article "GSM Issue-UE sends SABM and gets a DM response instead of
UA response":
This issue is most commonly observed in GSM networks where in UE sends
SABM and expects network to send UA response but it ends up receiving
DM response from the network. SABM stands for Set asynchronous balanced
mode, UA stands for Unnumbered Acknowledge and DA stands for
Disconnected Mode.
An RLP entity can be in one of two modes:
- Asynchronous Balanced Mode (ABM)
- Asynchronous Disconnected Mode (ADM)
Currently Linux kernel closes the control dlci after several retries
in gsm_dlci_t1() on DM. This causes n_gsm /dev/gsmtty ports to produce
error code -EL2HLT when trying to open them as the closing of control
dlci has already set gsm->dead.
Let's fix the issue by allowing control dlci stay in ADM mode after the
retries so the /dev/gsmtty ports can be opened and used. It seems that
it might take several attempts to get any response from the control
dlci, so it's best to allow ADM mode only after the SABM retries are
done.
Note that for droid 4 additional patches are needed to mux the ttyS0
pins and to toggle RTS gpio_149 to wake up the mdm6600 modem are also
needed to use n_gsm. And the mdm6600 modem needs to be powered on.
Cc: linux-serial@vger.kernel.org
Cc: Alan Cox <alan@llwyncelyn.cymru>
Cc: Jiri Prchal <jiri.prchal@aksignal.cz>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Michael Scott <michael.scott@linaro.org>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Russ Gorby <russ.gorby@intel.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/n_gsm.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -1467,6 +1467,10 @@ static void gsm_dlci_open(struct gsm_dlc
* in which case an opening port goes back to closed and a closing port
* is simply put into closed state (any further frames from the other
* end will get a DM response)
+ *
+ * Some control dlci can stay in ADM mode with other dlci working just
+ * fine. In that case we can just keep the control dlci open after the
+ * DLCI_OPENING retries time out.
*/
static void gsm_dlci_t1(unsigned long data)
@@ -1480,8 +1484,15 @@ static void gsm_dlci_t1(unsigned long da
if (dlci->retries) {
gsm_command(dlci->gsm, dlci->addr, SABM|PF);
mod_timer(&dlci->t1, jiffies + gsm->t1 * HZ / 100);
- } else
+ } else if (!dlci->addr && gsm->control == (DM | PF)) {
+ if (debug & 8)
+ pr_info("DLCI %d opening in ADM mode.\n",
+ dlci->addr);
+ gsm_dlci_open(dlci);
+ } else {
gsm_dlci_close(dlci);
+ }
+
break;
case DLCI_CLOSING:
dlci->retries--;
@@ -1499,8 +1510,8 @@ static void gsm_dlci_t1(unsigned long da
* @dlci: DLCI to open
*
* Commence opening a DLCI from the Linux side. We issue SABM messages
- * to the modem which should then reply with a UA, at which point we
- * will move into open state. Opening is done asynchronously with retry
+ * to the modem which should then reply with a UA or ADM, at which point
+ * we will move into open state. Opening is done asynchronously with retry
* running off timers and the responses.
*/
^ permalink raw reply
* [PATCH 3.18 095/121] tty: n_gsm: Allow ADM response in addition to UA for control dlci
From: Greg Kroah-Hartman @ 2018-04-11 18:36 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, linux-serial, Alan Cox, Jiri Prchal,
Jiri Slaby, Marcel Partap, Michael Scott, Peter Hurley,
Russ Gorby, Sascha Hauer, Sebastian Reichel, Tony Lindgren,
Sasha Levin
In-Reply-To: <20180411183456.195010921@linuxfoundation.org>
3.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Lindgren <tony@atomide.com>
[ Upstream commit ea3d8465ab9b3e01be329ac5195970a84bef76c5 ]
Some devices have the control dlci stay in ADM mode instead of the UA
mode. This can seen at least on droid 4 when trying to open the ts
27.010 mux port. Enabling n_gsm debug mode shows the control dlci
always respond with DM to SABM instead of UA:
# modprobe n_gsm debug=0xff
# ldattach -d GSM0710 /dev/ttyS0 &
gsmld_output: 00000000: f9 03 3f 01 1c f9
--> 0) C: SABM(P)
gsmld_receive: 00000000: f9 03 1f 01 36 f9
<-- 0) C: DM(P)
...
$ minicom -D /dev/gsmtty1
minicom: cannot open /dev/gsmtty1: No error information
$ strace minicom -D /dev/gsmtty1
...
open("/dev/gsmtty1", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = -1 EL2HLT
Note that this is different issue from other n_gsm -EL2HLT issues such
as timeouts when the control dlci does not respond at all.
The ADM mode seems to be a quite common according to "RF Wireless World"
article "GSM Issue-UE sends SABM and gets a DM response instead of
UA response":
This issue is most commonly observed in GSM networks where in UE sends
SABM and expects network to send UA response but it ends up receiving
DM response from the network. SABM stands for Set asynchronous balanced
mode, UA stands for Unnumbered Acknowledge and DA stands for
Disconnected Mode.
An RLP entity can be in one of two modes:
- Asynchronous Balanced Mode (ABM)
- Asynchronous Disconnected Mode (ADM)
Currently Linux kernel closes the control dlci after several retries
in gsm_dlci_t1() on DM. This causes n_gsm /dev/gsmtty ports to produce
error code -EL2HLT when trying to open them as the closing of control
dlci has already set gsm->dead.
Let's fix the issue by allowing control dlci stay in ADM mode after the
retries so the /dev/gsmtty ports can be opened and used. It seems that
it might take several attempts to get any response from the control
dlci, so it's best to allow ADM mode only after the SABM retries are
done.
Note that for droid 4 additional patches are needed to mux the ttyS0
pins and to toggle RTS gpio_149 to wake up the mdm6600 modem are also
needed to use n_gsm. And the mdm6600 modem needs to be powered on.
Cc: linux-serial@vger.kernel.org
Cc: Alan Cox <alan@llwyncelyn.cymru>
Cc: Jiri Prchal <jiri.prchal@aksignal.cz>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Michael Scott <michael.scott@linaro.org>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Russ Gorby <russ.gorby@intel.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/n_gsm.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -1467,6 +1467,10 @@ static void gsm_dlci_open(struct gsm_dlc
* in which case an opening port goes back to closed and a closing port
* is simply put into closed state (any further frames from the other
* end will get a DM response)
+ *
+ * Some control dlci can stay in ADM mode with other dlci working just
+ * fine. In that case we can just keep the control dlci open after the
+ * DLCI_OPENING retries time out.
*/
static void gsm_dlci_t1(unsigned long data)
@@ -1480,8 +1484,15 @@ static void gsm_dlci_t1(unsigned long da
if (dlci->retries) {
gsm_command(dlci->gsm, dlci->addr, SABM|PF);
mod_timer(&dlci->t1, jiffies + gsm->t1 * HZ / 100);
- } else
+ } else if (!dlci->addr && gsm->control == (DM | PF)) {
+ if (debug & 8)
+ pr_info("DLCI %d opening in ADM mode.\n",
+ dlci->addr);
+ gsm_dlci_open(dlci);
+ } else {
gsm_dlci_close(dlci);
+ }
+
break;
case DLCI_CLOSING:
dlci->retries--;
@@ -1499,8 +1510,8 @@ static void gsm_dlci_t1(unsigned long da
* @dlci: DLCI to open
*
* Commence opening a DLCI from the Linux side. We issue SABM messages
- * to the modem which should then reply with a UA, at which point we
- * will move into open state. Opening is done asynchronously with retry
+ * to the modem which should then reply with a UA or ADM, at which point
+ * we will move into open state. Opening is done asynchronously with retry
* running off timers and the responses.
*/
^ permalink raw reply
* [PATCH 4.14 064/138] tty: n_gsm: Allow ADM response in addition to UA for control dlci
From: Greg Kroah-Hartman @ 2018-04-10 22:24 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, linux-serial, Alan Cox, Jiri Prchal,
Jiri Slaby, Marcel Partap, Michael Scott, Peter Hurley,
Russ Gorby, Sascha Hauer, Sebastian Reichel, Tony Lindgren,
Sasha Levin
In-Reply-To: <20180410212902.121524696@linuxfoundation.org>
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Lindgren <tony@atomide.com>
[ Upstream commit ea3d8465ab9b3e01be329ac5195970a84bef76c5 ]
Some devices have the control dlci stay in ADM mode instead of the UA
mode. This can seen at least on droid 4 when trying to open the ts
27.010 mux port. Enabling n_gsm debug mode shows the control dlci
always respond with DM to SABM instead of UA:
# modprobe n_gsm debug=0xff
# ldattach -d GSM0710 /dev/ttyS0 &
gsmld_output: 00000000: f9 03 3f 01 1c f9
--> 0) C: SABM(P)
gsmld_receive: 00000000: f9 03 1f 01 36 f9
<-- 0) C: DM(P)
...
$ minicom -D /dev/gsmtty1
minicom: cannot open /dev/gsmtty1: No error information
$ strace minicom -D /dev/gsmtty1
...
open("/dev/gsmtty1", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = -1 EL2HLT
Note that this is different issue from other n_gsm -EL2HLT issues such
as timeouts when the control dlci does not respond at all.
The ADM mode seems to be a quite common according to "RF Wireless World"
article "GSM Issue-UE sends SABM and gets a DM response instead of
UA response":
This issue is most commonly observed in GSM networks where in UE sends
SABM and expects network to send UA response but it ends up receiving
DM response from the network. SABM stands for Set asynchronous balanced
mode, UA stands for Unnumbered Acknowledge and DA stands for
Disconnected Mode.
An RLP entity can be in one of two modes:
- Asynchronous Balanced Mode (ABM)
- Asynchronous Disconnected Mode (ADM)
Currently Linux kernel closes the control dlci after several retries
in gsm_dlci_t1() on DM. This causes n_gsm /dev/gsmtty ports to produce
error code -EL2HLT when trying to open them as the closing of control
dlci has already set gsm->dead.
Let's fix the issue by allowing control dlci stay in ADM mode after the
retries so the /dev/gsmtty ports can be opened and used. It seems that
it might take several attempts to get any response from the control
dlci, so it's best to allow ADM mode only after the SABM retries are
done.
Note that for droid 4 additional patches are needed to mux the ttyS0
pins and to toggle RTS gpio_149 to wake up the mdm6600 modem are also
needed to use n_gsm. And the mdm6600 modem needs to be powered on.
Cc: linux-serial@vger.kernel.org
Cc: Alan Cox <alan@llwyncelyn.cymru>
Cc: Jiri Prchal <jiri.prchal@aksignal.cz>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Michael Scott <michael.scott@linaro.org>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Russ Gorby <russ.gorby@intel.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/n_gsm.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -1463,6 +1463,10 @@ static void gsm_dlci_open(struct gsm_dlc
* in which case an opening port goes back to closed and a closing port
* is simply put into closed state (any further frames from the other
* end will get a DM response)
+ *
+ * Some control dlci can stay in ADM mode with other dlci working just
+ * fine. In that case we can just keep the control dlci open after the
+ * DLCI_OPENING retries time out.
*/
static void gsm_dlci_t1(unsigned long data)
@@ -1476,8 +1480,15 @@ static void gsm_dlci_t1(unsigned long da
if (dlci->retries) {
gsm_command(dlci->gsm, dlci->addr, SABM|PF);
mod_timer(&dlci->t1, jiffies + gsm->t1 * HZ / 100);
- } else
+ } else if (!dlci->addr && gsm->control == (DM | PF)) {
+ if (debug & 8)
+ pr_info("DLCI %d opening in ADM mode.\n",
+ dlci->addr);
+ gsm_dlci_open(dlci);
+ } else {
gsm_dlci_close(dlci);
+ }
+
break;
case DLCI_CLOSING:
dlci->retries--;
@@ -1495,8 +1506,8 @@ static void gsm_dlci_t1(unsigned long da
* @dlci: DLCI to open
*
* Commence opening a DLCI from the Linux side. We issue SABM messages
- * to the modem which should then reply with a UA, at which point we
- * will move into open state. Opening is done asynchronously with retry
+ * to the modem which should then reply with a UA or ADM, at which point
+ * we will move into open state. Opening is done asynchronously with retry
* running off timers and the responses.
*/
^ permalink raw reply
* [PATCH 4.15 082/168] tty: n_gsm: Allow ADM response in addition to UA for control dlci
From: Greg Kroah-Hartman @ 2018-04-10 22:23 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, linux-serial, Alan Cox, Jiri Prchal,
Jiri Slaby, Marcel Partap, Michael Scott, Peter Hurley,
Russ Gorby, Sascha Hauer, Sebastian Reichel, Tony Lindgren,
Sasha Levin
In-Reply-To: <20180410212800.144079021@linuxfoundation.org>
4.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Lindgren <tony@atomide.com>
[ Upstream commit ea3d8465ab9b3e01be329ac5195970a84bef76c5 ]
Some devices have the control dlci stay in ADM mode instead of the UA
mode. This can seen at least on droid 4 when trying to open the ts
27.010 mux port. Enabling n_gsm debug mode shows the control dlci
always respond with DM to SABM instead of UA:
# modprobe n_gsm debug=0xff
# ldattach -d GSM0710 /dev/ttyS0 &
gsmld_output: 00000000: f9 03 3f 01 1c f9
--> 0) C: SABM(P)
gsmld_receive: 00000000: f9 03 1f 01 36 f9
<-- 0) C: DM(P)
...
$ minicom -D /dev/gsmtty1
minicom: cannot open /dev/gsmtty1: No error information
$ strace minicom -D /dev/gsmtty1
...
open("/dev/gsmtty1", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = -1 EL2HLT
Note that this is different issue from other n_gsm -EL2HLT issues such
as timeouts when the control dlci does not respond at all.
The ADM mode seems to be a quite common according to "RF Wireless World"
article "GSM Issue-UE sends SABM and gets a DM response instead of
UA response":
This issue is most commonly observed in GSM networks where in UE sends
SABM and expects network to send UA response but it ends up receiving
DM response from the network. SABM stands for Set asynchronous balanced
mode, UA stands for Unnumbered Acknowledge and DA stands for
Disconnected Mode.
An RLP entity can be in one of two modes:
- Asynchronous Balanced Mode (ABM)
- Asynchronous Disconnected Mode (ADM)
Currently Linux kernel closes the control dlci after several retries
in gsm_dlci_t1() on DM. This causes n_gsm /dev/gsmtty ports to produce
error code -EL2HLT when trying to open them as the closing of control
dlci has already set gsm->dead.
Let's fix the issue by allowing control dlci stay in ADM mode after the
retries so the /dev/gsmtty ports can be opened and used. It seems that
it might take several attempts to get any response from the control
dlci, so it's best to allow ADM mode only after the SABM retries are
done.
Note that for droid 4 additional patches are needed to mux the ttyS0
pins and to toggle RTS gpio_149 to wake up the mdm6600 modem are also
needed to use n_gsm. And the mdm6600 modem needs to be powered on.
Cc: linux-serial@vger.kernel.org
Cc: Alan Cox <alan@llwyncelyn.cymru>
Cc: Jiri Prchal <jiri.prchal@aksignal.cz>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Michael Scott <michael.scott@linaro.org>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Russ Gorby <russ.gorby@intel.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/n_gsm.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -1451,6 +1451,10 @@ static void gsm_dlci_open(struct gsm_dlc
* in which case an opening port goes back to closed and a closing port
* is simply put into closed state (any further frames from the other
* end will get a DM response)
+ *
+ * Some control dlci can stay in ADM mode with other dlci working just
+ * fine. In that case we can just keep the control dlci open after the
+ * DLCI_OPENING retries time out.
*/
static void gsm_dlci_t1(struct timer_list *t)
@@ -1464,8 +1468,15 @@ static void gsm_dlci_t1(struct timer_lis
if (dlci->retries) {
gsm_command(dlci->gsm, dlci->addr, SABM|PF);
mod_timer(&dlci->t1, jiffies + gsm->t1 * HZ / 100);
- } else
+ } else if (!dlci->addr && gsm->control == (DM | PF)) {
+ if (debug & 8)
+ pr_info("DLCI %d opening in ADM mode.\n",
+ dlci->addr);
+ gsm_dlci_open(dlci);
+ } else {
gsm_dlci_close(dlci);
+ }
+
break;
case DLCI_CLOSING:
dlci->retries--;
@@ -1483,8 +1494,8 @@ static void gsm_dlci_t1(struct timer_lis
* @dlci: DLCI to open
*
* Commence opening a DLCI from the Linux side. We issue SABM messages
- * to the modem which should then reply with a UA, at which point we
- * will move into open state. Opening is done asynchronously with retry
+ * to the modem which should then reply with a UA or ADM, at which point
+ * we will move into open state. Opening is done asynchronously with retry
* running off timers and the responses.
*/
^ permalink raw reply
* Re: [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
From: Tony Lindgren @ 2018-04-10 13:43 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg Kroah-Hartman, linux-kernel, linux-serial, Alan Cox,
Dan Williams, Jiri Prchal, Jiri Slaby, Marcel Partap,
Merlijn Wajer, Michael Nazzareno Trimarchi, Michael Scott,
Peter Hurley, Russ Gorby, Sascha Hauer, Sebastian Reichel
In-Reply-To: <20180410110944.GB13697@amd>
* Pavel Machek <pavel@ucw.cz> [180410 11:11]:
> Should the modem respond to AT commands on ttyS0? I launched minicom
> (115200 8N1) and I'm not getting any responses.
Not that I know. At least I never got anything out of it. But who knows,
maybe it is in normal mode initially during boot or when mdm6600 is
being flashed.
Regards,
Tony
^ permalink raw reply
* [PATCH] tty: serial: xuartps: Setup early console when uartclk is also passed
From: Michal Simek @ 2018-04-10 13:33 UTC (permalink / raw)
To: linux-kernel, monstr
Cc: Jiri Slaby, linux-serial, Greg Kroah-Hartman, linux-arm-kernel
Baudrate calculation depends on requested baudrate and uart clock.
This patch is checking that uartclk is also passed.
The same logic is used 8250_early.c/init_port function.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
drivers/tty/serial/xilinx_uartps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index b9b2bc76bcac..a654cda203c7 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1181,7 +1181,7 @@ static int __init cdns_early_console_setup(struct earlycon_device *device,
/* only set baud if specified on command line - otherwise
* assume it has been initialized by a boot loader.
*/
- if (device->baud) {
+ if (port->uartclk && device->baud) {
u32 cd = 0, bdiv = 0;
u32 mr;
int div8;
--
1.9.1
^ permalink raw reply related
* [PATCH] earlycon: Initialize port->uartclk based on clock-frequency property
From: Michal Simek @ 2018-04-10 13:32 UTC (permalink / raw)
To: linux-kernel, monstr, devicetree, Rob Herring
Cc: Greg Kroah-Hartman, linux-serial, Jiri Slaby
On DT based platforms when current-speed property is present baudrate
is setup. Also port->uartclk is initialized to bogus BASE_BAUD * 16
value. Drivers like uartps/ns16550 contain logic when baudrate and
uartclk is used for baudrate calculation.
The patch is reading optional clock-frequency property to replace bogus
BASE_BAUD * 16 calculation to have proper baudrate calculation.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
---
We should add documentation for current-speed, reg-offset, reg-shift,
big-endian, native-endian, reg-io-width and clock-frequency to any
generic location because they are all optional properties for all DT
earlycon drivers through of_setup_earlycon.
---
drivers/tty/serial/earlycon.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index a24278380fec..eb1f84258c44 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -279,6 +279,10 @@ int __init of_setup_earlycon(const struct earlycon_id *match,
if (val)
early_console_dev.baud = be32_to_cpu(*val);
+ val = of_get_flat_dt_prop(node, "clock-frequency", NULL);
+ if (val)
+ port->uartclk = be32_to_cpu(*val);
+
if (options) {
early_console_dev.baud = simple_strtoul(options, NULL, 0);
strlcpy(early_console_dev.options, options,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
From: Pavel Machek @ 2018-04-10 11:09 UTC (permalink / raw)
To: Tony Lindgren
Cc: Greg Kroah-Hartman, linux-kernel, linux-serial, Alan Cox,
Dan Williams, Jiri Prchal, Jiri Slaby, Marcel Partap,
Merlijn Wajer, Michael Nazzareno Trimarchi, Michael Scott,
Peter Hurley, Russ Gorby, Sascha Hauer, Sebastian Reichel
In-Reply-To: <20180409134259.GO5700@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]
On Mon 2018-04-09 06:42:59, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [180409 10:56]:
> > Ok, I should have all that enabled. But droid4-ngsm still fails:
> >
> > user@devuan:/my/droid4-ngsm$ sudo ./droid4-ngsm
> > Starting ngsm..
> > Testing ngsm..
> > Could not open /dev/gsmtty1: Level 2 halted
> > Trying to start ngsm again: Level 2 halted
> > Starting ngsm..
>
> I guess you must have phy-mapphone-mdm6600 enabled as you a have
> working modem over USB. What do you see in dmesg if you enable n_gsm
> debug with modprobe n_gsm debug=0xff or on kernel cmdline?
Ok, I guess I can do that, but first:
Should the modem respond to AT commands on ttyS0? I launched minicom
(115200 8N1) and I'm not getting any responses.
> > commit 984c7706ff180e33096c57183435d925cb644576 says:
> >
> > ARM: dts: omap4-droid4: Configure uart1 pins
> >
> > These are needed to use the n_gsm driver for TS 27.010 UART
> > multiplexing. Note that support for the OOB wake gpio is still
> > missing so the UART is not yet usable for n_gsm.
> >
> > ...am I still missing the OOB wake gpio support?
>
> We can get away without OOB wake gpio for a while as mdm6600 is not
> yet suspended over USB. But if you have manually suspended mdm6600
> USB interface via /sys, then it won't respond properly on n_gsm
> either.
Ahha, ok.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge
From: Aaron Durbin @ 2018-04-09 16:00 UTC (permalink / raw)
To: Alan Cox
Cc: Aaron Durbin, Andy Shevchenko, Daniel Kurtz,
Ricardo Ribalda Delgado, Greg Kroah-Hartman, Jiri Slaby,
Marc Gonzalez, Doug Anderson, Matt Redfearn, Jeffy,
open list:SERIAL DRIVERS, Linux Kernel Mailing List
In-Reply-To: <20180406144713.30d1ca00@alans-desktop>
On Fri, Apr 6, 2018 at 7:47 AM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
>> But we don't have the full ACPI interpreter up in the early part of
>> the kernel. All these 'early' devices have their own setup/config
>> which is the source of the issue. Or maybe I am wrong about the full
>> interpreter and the early drivers are just not taking advantage of the
>> ACPI device binding?
>
> In very early boot with serial console you just have to pray. No change
> there. Once ACPI comes up you however have the information to populate
> everything and configure correctly.
>
> So it should work fine except for kernel hackers trying to do early boot
> debug, which is a small (but important) cornercase ?
Yes, I think we're on the same page. This patch series is trying to
get the early console working correctly given the current code
assumptions.
-Aaron
^ permalink raw reply
* Re: [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
From: Tony Lindgren @ 2018-04-09 13:42 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg Kroah-Hartman, linux-kernel, linux-serial, Alan Cox,
Dan Williams, Jiri Prchal, Jiri Slaby, Marcel Partap,
Merlijn Wajer, Michael Nazzareno Trimarchi, Michael Scott,
Peter Hurley, Russ Gorby, Sascha Hauer, Sebastian Reichel
In-Reply-To: <20180409105407.GA15315@amd>
* Pavel Machek <pavel@ucw.cz> [180409 10:56]:
> Ok, I should have all that enabled. But droid4-ngsm still fails:
>
> user@devuan:/my/droid4-ngsm$ sudo ./droid4-ngsm
> Starting ngsm..
> Testing ngsm..
> Could not open /dev/gsmtty1: Level 2 halted
> Trying to start ngsm again: Level 2 halted
> Starting ngsm..
I guess you must have phy-mapphone-mdm6600 enabled as you a have
working modem over USB. What do you see in dmesg if you enable n_gsm
debug with modprobe n_gsm debug=0xff or on kernel cmdline?
> commit 984c7706ff180e33096c57183435d925cb644576 says:
>
> ARM: dts: omap4-droid4: Configure uart1 pins
>
> These are needed to use the n_gsm driver for TS 27.010 UART
> multiplexing. Note that support for the OOB wake gpio is still
> missing so the UART is not yet usable for n_gsm.
>
> ...am I still missing the OOB wake gpio support?
We can get away without OOB wake gpio for a while as mdm6600 is not
yet suspended over USB. But if you have manually suspended mdm6600
USB interface via /sys, then it won't respond properly on n_gsm
either.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
From: Pavel Machek @ 2018-04-09 10:54 UTC (permalink / raw)
To: Tony Lindgren
Cc: Greg Kroah-Hartman, linux-kernel, linux-serial, Alan Cox,
Dan Williams, Jiri Prchal, Jiri Slaby, Marcel Partap,
Merlijn Wajer, Michael Nazzareno Trimarchi, Michael Scott,
Peter Hurley, Russ Gorby, Sascha Hauer, Sebastian Reichel
In-Reply-To: <20180408235740.GN5700@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]
Hi!
> > > > Do you have a tool to use and a script?
> > >
> > > Yes I used the shell script I posted earlier, but forgot it also
> > > needs the ldattach done.
> > >
> > > Anyways, last night and today I wrote a quick test utility called
> > > droid4-ngsm that initializes things and I can use to do some
> > > experiments to get the ts27010 channel proxying to W3GLTE also
> > > going:
> > >
> > > http://github.com/tmlind/droid4-ngsm/
> >
> > Ok, now i'm confused. It wants to bind to ttyS0, but modem is on
> > ttyUSB4 AFAICT? Or is the modem connected to serial port, too? (Do I
> > need to enable some more drivers for that?)
> >
> > I do have ttyS0, but I don't think there's anything attached there. Or
> > is ttyS0 for the LTE modem?
>
> The ttyS0 is connected to mdm6600, and ttyUSB4 seems to be
> some buggy subset of ttyS0 n_gsm dlci1. You need need at least
> the following commits in current mainline kernel:
>
> 984c7706ff18 ("ARM: dts: omap4-droid4: Configure uart1 pins")
> e5b9fd7bdeb5 ("ARM: dts: omap4-droid4: Configure MDM6600 USB PHY")
>
> And then you need PHY_MAPPHONE_MDM6600 and CONFIG_N_GSM enabled.
Ok, I should have all that enabled. But droid4-ngsm still fails:
user@devuan:/my/droid4-ngsm$ sudo ./droid4-ngsm
Starting ngsm..
Testing ngsm..
Could not open /dev/gsmtty1: Level 2 halted
Trying to start ngsm again: Level 2 halted
Starting ngsm..
commit 984c7706ff180e33096c57183435d925cb644576 says:
ARM: dts: omap4-droid4: Configure uart1 pins
These are needed to use the n_gsm driver for TS 27.010 UART
multiplexing. Note that support for the OOB wake gpio is still
missing so the UART is not yet usable for n_gsm.
...am I still missing the OOB wake gpio support?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
From: Tony Lindgren @ 2018-04-08 23:57 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg Kroah-Hartman, linux-kernel, linux-serial, Alan Cox,
Dan Williams, Jiri Prchal, Jiri Slaby, Marcel Partap,
Merlijn Wajer, Michael Nazzareno Trimarchi, Michael Scott,
Peter Hurley, Russ Gorby, Sascha Hauer, Sebastian Reichel
In-Reply-To: <20180408190600.GA24342@amd>
* Pavel Machek <pavel@ucw.cz> [180408 19:07]:
> Hi!
>
> > > Do you have a tool to use and a script?
> >
> > Yes I used the shell script I posted earlier, but forgot it also
> > needs the ldattach done.
> >
> > Anyways, last night and today I wrote a quick test utility called
> > droid4-ngsm that initializes things and I can use to do some
> > experiments to get the ts27010 channel proxying to W3GLTE also
> > going:
> >
> > http://github.com/tmlind/droid4-ngsm/
>
> Ok, now i'm confused. It wants to bind to ttyS0, but modem is on
> ttyUSB4 AFAICT? Or is the modem connected to serial port, too? (Do I
> need to enable some more drivers for that?)
>
> I do have ttyS0, but I don't think there's anything attached there. Or
> is ttyS0 for the LTE modem?
The ttyS0 is connected to mdm6600, and ttyUSB4 seems to be
some buggy subset of ttyS0 n_gsm dlci1. You need need at least
the following commits in current mainline kernel:
984c7706ff18 ("ARM: dts: omap4-droid4: Configure uart1 pins")
e5b9fd7bdeb5 ("ARM: dts: omap4-droid4: Configure MDM6600 USB PHY")
And then you need PHY_MAPPHONE_MDM6600 and CONFIG_N_GSM enabled.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
From: Pavel Machek @ 2018-04-08 19:06 UTC (permalink / raw)
To: Tony Lindgren
Cc: Greg Kroah-Hartman, linux-kernel, linux-serial, Alan Cox,
Dan Williams, Jiri Prchal, Jiri Slaby, Marcel Partap,
Merlijn Wajer, Michael Nazzareno Trimarchi, Michael Scott,
Peter Hurley, Russ Gorby, Sascha Hauer, Sebastian Reichel
In-Reply-To: <20180408165038.GM5700@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]
Hi!
> > Do you have a tool to use and a script?
>
> Yes I used the shell script I posted earlier, but forgot it also
> needs the ldattach done.
>
> Anyways, last night and today I wrote a quick test utility called
> droid4-ngsm that initializes things and I can use to do some
> experiments to get the ts27010 channel proxying to W3GLTE also
> going:
>
> http://github.com/tmlind/droid4-ngsm/
Ok, now i'm confused. It wants to bind to ttyS0, but modem is on
ttyUSB4 AFAICT? Or is the modem connected to serial port, too? (Do I
need to enable some more drivers for that?)
I do have ttyS0, but I don't think there's anything attached there. Or
is ttyS0 for the LTE modem?
> Sorry could not resist adding a test call feature too :)
:-)
> Hmm it might be best to add the ts27010 support and proxying
> eventually to ModemManager? I think ofono and others could still
> use the /dev/gsmtty* ports for the modem as needed too?
I'm not sure how the userland should be designed...
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
From: Tony Lindgren @ 2018-04-08 16:50 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg Kroah-Hartman, linux-kernel, linux-serial, Alan Cox,
Dan Williams, Jiri Prchal, Jiri Slaby, Marcel Partap,
Merlijn Wajer, Michael Nazzareno Trimarchi, Michael Scott,
Peter Hurley, Russ Gorby, Sascha Hauer, Sebastian Reichel
In-Reply-To: <20180408090259.GA8185@amd>
* Pavel Machek <pavel@ucw.cz> [180408 09:04]:
> I guess I'd like to test this on Droid4; there are fso-gsm0710muxd and
> gsm0710muxd packages in Debian, but I assume those do multiplexing in
> userspace and thus are not suitable?
I don't think those are needed, we now have kernel n_gsm driver do
most of the work for us :) Doing ldattach config is still needed,
but eventually we should have a serdev driver do that too for us.
So apps should only do the ldattach part if node yet already done,
and just attempt to use /dev/gsmtty* ports directly.
I did get serdev working with n_gsm several weeks ago with horrible
hacks, it needs quite a bit more work though before it's ready..
Then we need to add proxying of some /dev/gsmtty* ports to W3GLTE to
get that working (US only AFAIK for the band). It might make sense
to add the proxy features to ModemManager eventually.
> Do you have a tool to use and a script?
Yes I used the shell script I posted earlier, but forgot it also
needs the ldattach done.
Anyways, last night and today I wrote a quick test utility called
droid4-ngsm that initializes things and I can use to do some
experiments to get the ts27010 channel proxying to W3GLTE also
going:
http://github.com/tmlind/droid4-ngsm/
Sorry could not resist adding a test call feature too :)
Hmm it might be best to add the ts27010 support and proxying
eventually to ModemManager? I think ofono and others could still
use the /dev/gsmtty* ports for the modem as needed too?
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
From: Pavel Machek @ 2018-04-08 9:02 UTC (permalink / raw)
To: Tony Lindgren
Cc: Greg Kroah-Hartman, linux-kernel, linux-serial, Alan Cox,
Dan Williams, Jiri Prchal, Jiri Slaby, Marcel Partap,
Merlijn Wajer, Michael Nazzareno Trimarchi, Michael Scott,
Peter Hurley, Russ Gorby, Sascha Hauer, Sebastian Reichel
In-Reply-To: <20180407171951.122759-1-tony@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]
Hi!
> Commit ea3d8465ab9b ("tty: n_gsm: Allow ADM response in addition to UA for
> control dlci") added support for DLCI to stay in Asynchronous Disconnected
> Mode (ADM). But we still get long delays waiting for commands to other
> DLCI to complete:
>
> --> 5) C: SABM(P)
> Q> 0) C: UIH(F)
> Q> 0) C: UIH(F)
> Q> 0) C: UIH(F)
> ...
>
> This happens because gsm_control_send() sets cretries timer to T2 that is
> by default set to 34. This will cause resend for T2 times for the control
> frame. In ADM mode, we will never get a response so the control frame, so
> retries are just delaying all the commands.
>
> Let's fix the issue by setting DLCI_MODE_ADM flag after detecting the ADM
> mode for the control DLCI. Then we can use that in gsm_control_send() to
> set retries to 1. This means the control frame will be sent once allowing
> the other end at an opportunity to switch from ADM to ABM mode.
>
> Note that retries will be decremented in gsm_control_retransmit() so
> we don't want to set it to 0 here.
Thanks!
I guess I'd like to test this on Droid4; there are fso-gsm0710muxd and
gsm0710muxd packages in Debian, but I assume those do multiplexing in
userspace and thus are not suitable?
Do you have a tool to use and a script?
Thanks and best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH 2/2] tty: n_gsm: Fix DLCI handling for ADM mode if debug & 2 is not set
From: Tony Lindgren @ 2018-04-07 17:19 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, linux-serial, Alan Cox, Dan Williams, Jiri Prchal,
Jiri Slaby, Marcel Partap, Merlijn Wajer,
Michael Nazzareno Trimarchi, Michael Scott, Pavel Machek,
Peter Hurley, Russ Gorby, Sascha Hauer, Sebastian Reichel
In-Reply-To: <20180407171951.122759-1-tony@atomide.com>
At least on droid 4 with control channel in ADM mode, there is no response
to Modem Status Command (MSC). Currently gsmtty_modem_update() expects to
have data in dlci->modem_rx unless debug & 2 is set. This means that on
droid 4, things only work if debug & 2 is set.
Let's fix the issue by ignoring empty dlci->modem_rx for ADM mode. In
the AMD mode, CMD_MSC will never respond and gsm_process_modem() won't
get called to set dlci->modem_rx.
And according to ts_127010v140000p.pdf, MSC is only relevant if basic
option is chosen, so let's test for that too.
Fixes: ea3d8465ab9b ("tty: n_gsm: Allow ADM response in addition to UA for
control dlci")
Cc: linux-serial@vger.kernel.org
Cc: Alan Cox <alan@llwyncelyn.cymru>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Jiri Prchal <jiri.prchal@aksignal.cz>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Cc: Michael Scott <michael.scott@linaro.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Russ Gorby <russ.gorby@intel.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/tty/n_gsm.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2871,11 +2871,22 @@ static int gsmtty_modem_update(struct gsm_dlci *dlci, u8 brk)
static int gsm_carrier_raised(struct tty_port *port)
{
struct gsm_dlci *dlci = container_of(port, struct gsm_dlci, port);
+ struct gsm_mux *gsm = dlci->gsm;
+
/* Not yet open so no carrier info */
if (dlci->state != DLCI_OPEN)
return 0;
if (debug & 2)
return 1;
+
+ /*
+ * Basic mode with control channel in ADM mode may not respond
+ * to CMD_MSC at all and modem_rx is empty.
+ */
+ if (gsm->encoding == 0 && gsm->dlci[0]->mode == DLCI_MODE_ADM &&
+ !dlci->modem_rx)
+ return 1;
+
return dlci->modem_rx & TIOCM_CD;
}
--
2.17.0
^ permalink raw reply
* [PATCH 1/2] tty: n_gsm: Fix long delays with control frame timeouts in ADM mode
From: Tony Lindgren @ 2018-04-07 17:19 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, linux-serial, Alan Cox, Dan Williams, Jiri Prchal,
Jiri Slaby, Marcel Partap, Merlijn Wajer,
Michael Nazzareno Trimarchi, Michael Scott, Pavel Machek,
Peter Hurley, Russ Gorby, Sascha Hauer, Sebastian Reichel
Commit ea3d8465ab9b ("tty: n_gsm: Allow ADM response in addition to UA for
control dlci") added support for DLCI to stay in Asynchronous Disconnected
Mode (ADM). But we still get long delays waiting for commands to other
DLCI to complete:
--> 5) C: SABM(P)
Q> 0) C: UIH(F)
Q> 0) C: UIH(F)
Q> 0) C: UIH(F)
...
This happens because gsm_control_send() sets cretries timer to T2 that is
by default set to 34. This will cause resend for T2 times for the control
frame. In ADM mode, we will never get a response so the control frame, so
retries are just delaying all the commands.
Let's fix the issue by setting DLCI_MODE_ADM flag after detecting the ADM
mode for the control DLCI. Then we can use that in gsm_control_send() to
set retries to 1. This means the control frame will be sent once allowing
the other end at an opportunity to switch from ADM to ABM mode.
Note that retries will be decremented in gsm_control_retransmit() so
we don't want to set it to 0 here.
Fixes: ea3d8465ab9b ("tty: n_gsm: Allow ADM response in addition to UA for
control dlci")
Cc: linux-serial@vger.kernel.org
Cc: Alan Cox <alan@llwyncelyn.cymru>
Cc: Dan Williams <dcbw@redhat.com>
Cc: Jiri Prchal <jiri.prchal@aksignal.cz>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Michael Nazzareno Trimarchi <michael@amarulasolutions.com>
Cc: Michael Scott <michael.scott@linaro.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Russ Gorby <russ.gorby@intel.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/tty/n_gsm.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -121,6 +121,9 @@ struct gsm_dlci {
struct mutex mutex;
/* Link layer */
+ int mode;
+#define DLCI_MODE_ABM 0 /* Normal Asynchronous Balanced Mode */
+#define DLCI_MODE_ADM 1 /* Asynchronous Disconnected Mode */
spinlock_t lock; /* Protects the internal state */
struct timer_list t1; /* Retransmit timer for SABM and UA */
int retries;
@@ -1364,7 +1367,13 @@ static struct gsm_control *gsm_control_send(struct gsm_mux *gsm,
ctrl->data = data;
ctrl->len = clen;
gsm->pending_cmd = ctrl;
- gsm->cretries = gsm->n2;
+
+ /* If DLCI0 is in ADM mode skip retries, it won't respond */
+ if (gsm->dlci[0]->mode == DLCI_MODE_ADM)
+ gsm->cretries = 1;
+ else
+ gsm->cretries = gsm->n2;
+
mod_timer(&gsm->t2_timer, jiffies + gsm->t2 * HZ / 100);
gsm_control_transmit(gsm, ctrl);
spin_unlock_irqrestore(&gsm->control_lock, flags);
@@ -1472,6 +1481,7 @@ static void gsm_dlci_t1(struct timer_list *t)
if (debug & 8)
pr_info("DLCI %d opening in ADM mode.\n",
dlci->addr);
+ dlci->mode = DLCI_MODE_ADM;
gsm_dlci_open(dlci);
} else {
gsm_dlci_close(dlci);
--
2.17.0
^ permalink raw reply
* [PATCH v6] earlycon: Use a pointer table to fix __earlycon_table stride
From: Daniel Kurtz @ 2018-04-06 23:21 UTC (permalink / raw)
Cc: Daniel Kurtz, Rob Herring, Frank Rowand, Greg Kroah-Hartman,
Jiri Slaby, Arnd Bergmann,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:SERIAL DRIVERS,
open list:GENERIC INCLUDE/ASM HEADER FILES
Commit 99492c39f39f ("earlycon: Fix __earlycon_table stride") tried to fix
__earlycon_table stride by forcing the earlycon_id struct alignment to 32
and asking the linker to 32-byte align the __earlycon_table symbol. This
fix was based on commit 07fca0e57fca92 ("tracing: Properly align linker
defined symbols") which tried a similar fix for the tracing subsystem.
However, this fix doesn't quite work because there is no guarantee that
gcc will place structures packed into an array format. In fact, gcc 4.9
chooses to 64-byte align these structs by inserting additional padding
between the entries because it has no clue that they are supposed to be in
an array. If we are unlucky, the linker will assign symbol
"__earlycon_table" to a 32-byte aligned address which does not correspond
to the 64-byte aligned contents of section "__earlycon_table".
To address this same problem, the fix to the tracing system was
subsequently re-implemented using a more robust table of pointers approach
by commits:
3d56e331b653 ("tracing: Replace syscall_meta_data struct array with pointer array")
654986462939 ("tracepoints: Fix section alignment using pointer array")
e4a9ea5ee7c8 ("tracing: Replace trace_event struct array with pointer array")
Let's use this same "array of pointers to structs" approach for
EARLYCON_TABLE.
Fixes: 99492c39f39f ("earlycon: Fix __earlycon_table stride")
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Suggested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
---
Changes since v2:
* Use __initconst instead of __initdata to avoid h8300 and alpha kbuild errors
Changes since v3:
* Fixed typos in commit message
Changes since v4:
* removed Change-Id: from commit message
Changes since v5:
* None, just re-posting per request from greg k-h
drivers/of/fdt.c | 7 +++++--
drivers/tty/serial/earlycon.c | 6 ++++--
include/asm-generic/vmlinux.lds.h | 2 +-
include/linux/serial_core.h | 21 ++++++++++++++-------
4 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 84aa9d676375..6da20b9688f7 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -942,7 +942,7 @@ int __init early_init_dt_scan_chosen_stdout(void)
int offset;
const char *p, *q, *options = NULL;
int l;
- const struct earlycon_id *match;
+ const struct earlycon_id **p_match;
const void *fdt = initial_boot_params;
offset = fdt_path_offset(fdt, "/chosen");
@@ -969,7 +969,10 @@ int __init early_init_dt_scan_chosen_stdout(void)
return 0;
}
- for (match = __earlycon_table; match < __earlycon_table_end; match++) {
+ for (p_match = __earlycon_table; p_match < __earlycon_table_end;
+ p_match++) {
+ const struct earlycon_id *match = *p_match;
+
if (!match->compatible[0])
continue;
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index a24278380fec..22683393a0f2 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -169,7 +169,7 @@ static int __init register_earlycon(char *buf, const struct earlycon_id *match)
*/
int __init setup_earlycon(char *buf)
{
- const struct earlycon_id *match;
+ const struct earlycon_id **p_match;
if (!buf || !buf[0])
return -EINVAL;
@@ -177,7 +177,9 @@ int __init setup_earlycon(char *buf)
if (early_con.flags & CON_ENABLED)
return -EALREADY;
- for (match = __earlycon_table; match < __earlycon_table_end; match++) {
+ for (p_match = __earlycon_table; p_match < __earlycon_table_end;
+ p_match++) {
+ const struct earlycon_id *match = *p_match;
size_t len = strlen(match->name);
if (strncmp(buf, match->name, len))
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 278841c75b97..af240573e482 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -188,7 +188,7 @@
#endif
#ifdef CONFIG_SERIAL_EARLYCON
-#define EARLYCON_TABLE() STRUCT_ALIGN(); \
+#define EARLYCON_TABLE() . = ALIGN(8); \
VMLINUX_SYMBOL(__earlycon_table) = .; \
KEEP(*(__earlycon_table)) \
VMLINUX_SYMBOL(__earlycon_table_end) = .;
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 1d356105f25a..b4c9fda9d833 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -351,10 +351,10 @@ struct earlycon_id {
char name[16];
char compatible[128];
int (*setup)(struct earlycon_device *, const char *options);
-} __aligned(32);
+};
-extern const struct earlycon_id __earlycon_table[];
-extern const struct earlycon_id __earlycon_table_end[];
+extern const struct earlycon_id *__earlycon_table[];
+extern const struct earlycon_id *__earlycon_table_end[];
#if defined(CONFIG_SERIAL_EARLYCON) && !defined(MODULE)
#define EARLYCON_USED_OR_UNUSED __used
@@ -362,12 +362,19 @@ extern const struct earlycon_id __earlycon_table_end[];
#define EARLYCON_USED_OR_UNUSED __maybe_unused
#endif
-#define OF_EARLYCON_DECLARE(_name, compat, fn) \
- static const struct earlycon_id __UNIQUE_ID(__earlycon_##_name) \
- EARLYCON_USED_OR_UNUSED __section(__earlycon_table) \
+#define _OF_EARLYCON_DECLARE(_name, compat, fn, unique_id) \
+ static const struct earlycon_id unique_id \
+ EARLYCON_USED_OR_UNUSED __initconst \
= { .name = __stringify(_name), \
.compatible = compat, \
- .setup = fn }
+ .setup = fn }; \
+ static const struct earlycon_id EARLYCON_USED_OR_UNUSED \
+ __section(__earlycon_table) \
+ * const __PASTE(__p, unique_id) = &unique_id
+
+#define OF_EARLYCON_DECLARE(_name, compat, fn) \
+ _OF_EARLYCON_DECLARE(_name, compat, fn, \
+ __UNIQUE_ID(__earlycon_##_name))
#define EARLYCON_DECLARE(_name, fn) OF_EARLYCON_DECLARE(_name, "", fn)
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge
From: Alan Cox @ 2018-04-06 13:47 UTC (permalink / raw)
To: Aaron Durbin
Cc: Andy Shevchenko, Daniel Kurtz, Ricardo Ribalda Delgado,
Greg Kroah-Hartman, Jiri Slaby, Marc Gonzalez, Doug Anderson,
Matt Redfearn, Jeffy, open list:SERIAL DRIVERS,
Linux Kernel Mailing List
In-Reply-To: <CAE2855tmMwbOWDOs-iJS7i35=Y7gt0xun4ApfhZyY9Kr5N3NJA@mail.gmail.com>
> But we don't have the full ACPI interpreter up in the early part of
> the kernel. All these 'early' devices have their own setup/config
> which is the source of the issue. Or maybe I am wrong about the full
> interpreter and the early drivers are just not taking advantage of the
> ACPI device binding?
In very early boot with serial console you just have to pray. No change
there. Once ACPI comes up you however have the information to populate
everything and configure correctly.
So it should work fine except for kernel hackers trying to do early boot
debug, which is a small (but important) cornercase ?
Alan
^ permalink raw reply
* Re: uart throughput
From: Alan Cox @ 2018-04-06 11:42 UTC (permalink / raw)
To: Muni Sekhar; +Cc: linux-serial, linux-kernel, kernelnewbies
In-Reply-To: <CAHhAz+io6_dS=+YO=Zd9rYuPomOOFtd2GsweKyvN1A4zKQZOVA@mail.gmail.com>
> The primary factor affecting UART throughput is the baud rate, apart
> from this any other factors affect the UART throughput?
UART
CPU power
interrupt latency
all the usual suspects.
> > For 4000000 bps uart baud rate, what should be the theoretical peak
> data throughput?
>
Depends entirely what the uart is wired to, how it works and how the
driver is written. If you've got bidirectional communication going on
then you also need to consider latency and windowing.
For a raw transfer over a decent UART with DMA with no post-processing I'd
expect you can do the full line rate but it may eat a lot of CPU time.
The uart code isn't particularly optimal for that kind of usage. It's not
impossible to fix by fast-pathing the non N_TTY line discipline cases but
nobody has found it a big enough pain to bother.
Alan
^ permalink raw reply
* Re: uart throughput
From: Greg KH @ 2018-04-05 19:19 UTC (permalink / raw)
To: Muni Sekhar; +Cc: linux-serial, linux-kernel, kernelnewbies
In-Reply-To: <CAHhAz+io6_dS=+YO=Zd9rYuPomOOFtd2GsweKyvN1A4zKQZOVA@mail.gmail.com>
On Thu, Apr 05, 2018 at 10:08:14PM +0530, Muni Sekhar wrote:
> Hi All,
>
>
> I’ve an uart hardware implemented on Xilinx FPGA image and it connects
> to host CPU(Intel based chip) on PCIe bus in Linux platform.
>
>
> The following parameters were fixed or varied when measuring the UART
> throughput in internal loopback mode(UART_RX and UART_TX pins were
> internally connected):
>
>
> • Uart baud rate
> • Parity Bit
> • Stop Bit(s)
>
>
> The primary factor affecting UART throughput is the baud rate, apart
> from this any other factors affect the UART throughput?
>
> For 4000000 bps uart baud rate, what should be the theoretical peak
> data throughput?
Um, you do know what "baud rate" means, right? And how stop bits and
parity are related to a baud rate?
Throughput all depends on a whole raft of different things. How exactly
have you measured this and where did you find any performance
bottlenecks?
thanks,
greg k-h
^ permalink raw reply
* uart throughput
From: Muni Sekhar @ 2018-04-05 16:38 UTC (permalink / raw)
To: linux-serial, linux-kernel, kernelnewbies
Hi All,
I’ve an uart hardware implemented on Xilinx FPGA image and it connects
to host CPU(Intel based chip) on PCIe bus in Linux platform.
The following parameters were fixed or varied when measuring the UART
throughput in internal loopback mode(UART_RX and UART_TX pins were
internally connected):
• Uart baud rate
• Parity Bit
• Stop Bit(s)
The primary factor affecting UART throughput is the baud rate, apart
from this any other factors affect the UART throughput?
For 4000000 bps uart baud rate, what should be the theoretical peak
data throughput?
--
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v2 00/21] Allow compile-testing NO_DMA (drivers)
From: Rob Herring @ 2018-04-05 0:32 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ulf Hansson, Wolfram Sang, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-fpga-u79uwXL29TY76Z2rM5mHXA,
open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM, Linux-ALSA,
Bjorn Andersson, Eric Anholt, netdev,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Linux I2C,
linux1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Christoph Hellwig, Stefan Wahren, Boris Brezillon,
James E . J . Bottomley, Herbert Xu,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger, Jassi Brar,
Marek Vasut, "open list:SERIAL DRIVERS" <linux-serial@
In-Reply-To: <1521208314-4783-1-git-send-email-geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
On Fri, Mar 16, 2018 at 8:51 AM, Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> Hi all,
>
> If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
> symbol bad_dma_ops, thus causing a link failure if it is ever used.
>
> The intention of this is twofold:
> 1. To catch users of the DMA API on systems that do no support the DMA
> mapping API,
> 2. To avoid building drivers that cannot work on such systems anyway.
>
> However, the disadvantage is that we have to keep on adding dependencies
> on HAS_DMA all over the place.
>
> Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or
> more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus
> already covering intention #2. Having to add an explicit dependency on
> HAS_DMA here is cumbersome, and hinders compile-testing.
The same can be said for CONFIG_IOMEM and CONFIG_OF. Any plans to
remove those too? CONFIG_IOMEM is mostly just a !CONFIG_UM option.
Rob
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox