linux-kernel - Re: [PATCHv6 0/4] n_gsm serdev support and protocol driver for droid4 modem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 25 Apr 2020 09:58:23 -0700
From:   Tony Lindgren <tony@...mide.com>
To:     Johan Hovold <johan@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh@...nel.org>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Lee Jones <lee.jones@...aro.org>, Jiri Slaby <jslaby@...e.cz>,
        Merlijn Wajer <merlijn@...zup.org>,
        Pavel Machek <pavel@....cz>,
        Peter Hurley <peter@...leysoftware.com>,
        Sebastian Reichel <sre@...nel.org>,
        linux-serial@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org
Subject: Re: [PATCHv6 0/4] n_gsm serdev support and protocol driver for
 droid4 modem

* Tony Lindgren <tony@...mide.com> [200423 23:28]:
> * Tony Lindgren <tony@...mide.com> [200423 15:38]:
> > * Johan Hovold <johan@...nel.org> [200423 11:44]:
> > > I'd rather see a generic implementation which can be used with other
> > > modems and that continues to expose a /dev/gsmttyN interface to which we
> > > could attach serdev clients instead (and not create a motmdm serdev
> > > replica of sorts).
> > 
> > Yeah this should be doable quite easily actually without really any of
> > the motorola driver code. It's a separate driver though, and not
> > usable for this case because of the custom layer.
> 
> Well here's a first take at the such a generic serdev-ngsm driver
> that depends on patch 1/4 of this series. All this does is configure
> a serial port for TS 27.010 adaption1, and brings up 16 /dev/gsmtty*
> devices. So no custom options for the binding so far, and no support
> for adding channel specific device drivers. But all that can be added
> naturally later on.

Just to clarify the difference between the generic serdev-ngsm case
and this modem..

In the generic case, channel specific Linux device drivers can just
use gsm_serdev_write() directly for things like GNSS driver, SIM
file system, audio and whatever the modems might have on separate
channels.

This Motorola modem needs custom read and write functions because
of the custom Motorola packet format on top of TS 27.010. So for
example, the motmdm_write() function stuffs the packet header, and
then just calls gsm_serdev_write().

So for the generic channel specific drivers, the driver just needs
to be able to do something like:

Configure devicetree for the drivers/tty/serdev/serdev-ngsm.c
to bring up the TS 27.010 port based on the compatible and
whatever port specific properties we may want use.

And then have the channel specific device drivers do something
like this:

gsm_serdev_ngsm_register();	/* TBD to add to serdev-ngsm.c */
gsm_serdev_register_dlci();	/* Already patched for n_gsm.c */
gsm_serdev_write();		/* Already patched for n_gsm.c */
...
gsm_serdev_unregister_dlci();	/* Already patched for n_gsm.c */
gsm_serdev_ngsm_unregister();	/* TBD to add to serdev-ngsm.c */

So I think we can limit the code in the generic serdev-ngsm.c to bring
up the TS 27.010, and then allow whatever channel specific device
drivers to register with it. I guess that should do for the generic
API.

Anybody got better suggestions?

Regards,

Tony