On Thu, 2017-01-12 at 10:01 -0600, Rob Herring wrote:
> On Sat, Jan 7, 2017 at 8:11 AM, Andy Shevchenko
> <[email protected]> wrote:
> > On Fri, 2017-01-06 at 10:26 -0600, Rob Herring wrote:
> > > Add a serdev controller driver for tty ports.
> > >
> > > The controller is registered with serdev when tty ports are
> > > registered
> > > with the TTY core. As the TTY core is built-in only, this has the
> > > side
> > > effect of making serdev built-in as well.
> > >
> > >
> > > +if SERIAL_DEV_BUS
> > > +
> > > +config SERIAL_DEV_CTRL_TTYPORT
> > > + bool "Serial device TTY port controller"
> > > + depends on TTY
> > > + depends on SERIAL_DEV_BUS=y
> >
> > Do you need one?
>
> Yes, otherwise the bus can be built as a module and this driver can
> still be enabled breaking the build. I could drop supporting building
> the bus as a module because as long as this is the only controller
> driver, it all has to be built-in.
Would
if SERIAL_DEV_BUS=y
work for you?
> Is there any desire/plan to make
> the TTY layer buildable as a module?
Have no idea.
> > > + serdev_controller_put(ctrl);
> > > + return ret;
> > > +}
> > > +
> > > +void serdev_tty_port_unregister(struct tty_port *port)
> > > +{
> > > + struct serdev_controller *ctrl = port->client_data;
> > > + struct serport *serport =
> > > serdev_controller_get_drvdata(ctrl);
> > > +
> > >
> > > + if (!serport)
> > > + return;
> >
> > Same question, whose responsibility to do this?
>
> I don't get the question. ctrl and serport can be NULL here so the
> caller can call this unconditionally.
Yes, you got it. And I get the answer.
--
Andy Shevchenko <[email protected]>
Intel Finland Oy
