[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200306123440.GA3691382@kroah.com>
Date: Fri, 6 Mar 2020 13:34:40 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Tony Lindgren <tony@...mide.com>
Cc: Lee Jones <lee.jones@...aro.org>,
Alan Cox <gnomes@...rguk.ukuu.org.uk>,
Jiri Slaby <jslaby@...e.cz>, Johan Hovold <johan@...nel.org>,
Merlijn Wajer <merlijn@...zup.org>,
Pavel Machek <pavel@....cz>,
Peter Hurley <peter@...leysoftware.com>,
Rob Herring <robh@...nel.org>,
Sebastian Reichel <sre@...nel.org>,
linux-serial@...r.kernel.org, devicetree@...r.kernel.org,
linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] mfd: motmdm: Add Motorola TS 27.010 serdev modem
driver for droid4
On Wed, Feb 26, 2020 at 06:43:08AM -0800, Tony Lindgren wrote:
> * Lee Jones <lee.jones@...aro.org> [200226 11:56]:
> > On Thu, 20 Feb 2020, Tony Lindgren wrote:
> >
> > > Many Motorola phones are controlling the modem using a custom variant
> > > of TS 27.010 serial line discipline. Devices on these modems have a
> > > dedicated TS 27.010 channel for features like audio mixer, GNSS, voice
> > > modem, SIM card reader and so on.
> > >
> > > This driver allows using various devices on the modem. In order to do
> > > that, we need to take care of the following three things:
> > >
> > > 1. Provide /dev/motmdm* character devices for apps to use for talking
> > > to the various devices on the modem
> > >
> > > 2. Handle Motorola custom protocol over TS 27.010 to make the channels
> > > usable for userspace
> > >
> > > 3. Coordinate PM runtime with the USB PHY because of shared GPIO pins
> > > with the USB PHY
> ...
> > > ---
> > > drivers/mfd/Kconfig | 9 +
> > > drivers/mfd/Makefile | 1 +
> > > drivers/mfd/motorola-mdm.c | 1200 ++++++++++++++++++++++++++++++++++++
> >
> > I'm not even going to start reviewing this as I can see, without even
> > looking at the code, that this has too much functionality (stuff that
> > does stuff) contained.
> >
> > Please move as much functionality out into the subsystems as
> > possible. Ideally, MFDs should be responsible for obtaining and
> > registering shared resources and registering child devices. Anything
> > else should be shifted out to an appropriate subsystem.
> >
> > MFD is not Misc.
>
> OK good point. So this is a serdev consumer driver that eventually will
> also provide serdev style access to few device drivers too for the
> device within the modem after decoding the Motorola specific protocol.
> No special need for this driver to be under drivers/mfd though.
>
> How about we add drivers/tty/serdev/protocol or similar directory for
> drivers like this?
Sure, that seems sane.
Powered by blists - more mailing lists