From: Daniel Starke <[email protected]>
Currently, changing the parameters of a DLCI gives no direct control to the
user whether this should trigger a channel reset or not. The decision is
solely made by the driver based on the assumption which parameter changes
are compatible or not. Therefore, the user has no means to perform an
automatic channel reset after parameter configuration for non-conflicting
changes.
Add the parameter 'flags' to 'gsm_dlci_config' to force a channel reset
after ioctl setting regardless of whether the changes made require this or
not by setting this to 'GSM_FL_RESTART'.
Note that 'GSM_FL_RESTART' is currently the only allow flag to allow
additions here.
Signed-off-by: Daniel Starke <[email protected]>
---
drivers/tty/n_gsm.c | 4 ++++
include/uapi/linux/gsmmux.h | 15 ++++++++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
v4 -> v5:
Changed GSM_FL_RESTART comment to be more specific about its use as
suggested in the review comment.
Please note that I cannot response to emails until August 7th. Felix Haase
will take over from our side for questions regarding this patch series or
the n_gsm.
Link: https://lore.kernel.org/all/DB9PR10MB5881B63FBBA7912DF5A7A6A8E0789@DB9PR10MB5881.EURPRD10.PROD.OUTLOOK.COM/
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index b411a26cc092..66edcf65a4dd 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -2532,6 +2532,8 @@ static int gsm_dlci_config(struct gsm_dlci *dlci, struct gsm_dlci_config *dc, in
return -EINVAL;
if (dc->k > 7)
return -EINVAL;
+ if (dc->flags & ~GSM_FL_RESTART) /* allow future extensions */
+ return -EINVAL;
/*
* See what is needed for reconfiguration
@@ -2546,6 +2548,8 @@ static int gsm_dlci_config(struct gsm_dlci *dlci, struct gsm_dlci_config *dc, in
/* Requires care */
if (dc->priority != dlci->prio)
need_restart = true;
+ if (dc->flags & GSM_FL_RESTART)
+ need_restart = true;
if ((open && gsm->wait_config) || need_restart)
need_open = true;
diff --git a/include/uapi/linux/gsmmux.h b/include/uapi/linux/gsmmux.h
index eb67884e5f38..e56e2d7ea6eb 100644
--- a/include/uapi/linux/gsmmux.h
+++ b/include/uapi/linux/gsmmux.h
@@ -2,10 +2,22 @@
#ifndef _LINUX_GSMMUX_H
#define _LINUX_GSMMUX_H
+#include <linux/const.h>
#include <linux/if.h>
#include <linux/ioctl.h>
#include <linux/types.h>
+/*
+ * flags definition for n_gsm
+ *
+ * Used by:
+ * struct gsm_dlci_config.flags
+ */
+/* Forces a DLCI reset if set. Otherwise, a DLCI reset is only done if
+ * incompatible settings were provided. Always cleared on retrieval.
+ */
+#define GSM_FL_RESTART _BITUL(0)
+
struct gsm_config
{
unsigned int adaption;
@@ -58,7 +70,8 @@ struct gsm_dlci_config {
__u32 priority; /* Priority (0 for default value) */
__u32 i; /* Frame type (1 = UIH, 2 = UI) */
__u32 k; /* Window size (0 for default value) */
- __u32 reserved[8]; /* For future use, must be initialized to zero */
+ __u32 flags; /* DLCI specific flags. */
+ __u32 reserved[7]; /* For future use, must be initialized to zero */
};
#define GSMIOC_GETCONF_DLCI _IOWR('G', 7, struct gsm_dlci_config)
--
2.34.1
On Wed, May 17, 2023 at 05:56:55PM +0200, D. Starke wrote:
> From: Daniel Starke <[email protected]>
>
> Currently, changing the parameters of a DLCI gives no direct control to the
> user whether this should trigger a channel reset or not. The decision is
> solely made by the driver based on the assumption which parameter changes
> are compatible or not. Therefore, the user has no means to perform an
> automatic channel reset after parameter configuration for non-conflicting
> changes.
>
> Add the parameter 'flags' to 'gsm_dlci_config' to force a channel reset
> after ioctl setting regardless of whether the changes made require this or
> not by setting this to 'GSM_FL_RESTART'.
>
> Note that 'GSM_FL_RESTART' is currently the only allow flag to allow
> additions here.
>
> Signed-off-by: Daniel Starke <[email protected]>
> ---
> drivers/tty/n_gsm.c | 4 ++++
> include/uapi/linux/gsmmux.h | 15 ++++++++++++++-
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> v4 -> v5:
> Changed GSM_FL_RESTART comment to be more specific about its use as
> suggested in the review comment.
>
> Please note that I cannot response to emails until August 7th. Felix Haase
> will take over from our side for questions regarding this patch series or
> the n_gsm.
>
> Link: https://lore.kernel.org/all/DB9PR10MB5881B63FBBA7912DF5A7A6A8E0789@DB9PR10MB5881.EURPRD10.PROD.OUTLOOK.COM/
Ok, I'll wait for a resend by Felix to consider these as having someone
be responsible for them if they cause problems is key :)
thanks,
greg k-h