On Sat, Jan 7, 2017 at 8:11 AM, Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> 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. Is there any desire/plan to make
the TTY layer buildable as a module?
>> + mutex_unlock(&serport->lock);
>> + return count;
>> +}
>> +
>> +static void ttyport_write_wakeup(struct tty_port *port)
>> +{
>> + struct serdev_controller *ctrl = port->client_data;
>> + struct serport *serport =
>> serdev_controller_get_drvdata(ctrl);
>> +
>> + clear_bit(TTY_DO_WRITE_WAKEUP, &port->tty->flags);
>
> This doesn't prevent to be called this function in parallel. Is it okay?
I believe it should be fine. This is essentially what all the wakeup
callbacks do for the ldisc based drivers.
>> +int serdev_tty_port_register(struct tty_port *port, struct device
>> *parent,
>> + struct tty_driver *drv, int idx)
>> +{
>> + struct serdev_controller *ctrl;
>> + struct serport *serport;
>> + int ret;
>> +
>> + if (!port || !drv || !parent || !parent->of_node)
>
> And if it's ACPI? Perhaps last is redundant.
Yes, fixed. We should only have the matching details in the core.
>
>> + return -ENODEV;
>> +
>> + ctrl = serdev_controller_alloc(parent, sizeof(struct
>> serport));
>> + if (!ctrl)
>> + return -ENOMEM;
>> + serport = serdev_controller_get_drvdata(ctrl);
>> +
>> + mutex_init(&serport->lock);
>> + serport->port = port;
>> + serport->tty_idx = idx;
>> + serport->tty_drv = drv;
>> +
>> + ctrl->ops = &ctrl_ops;
>> +
>> + ret = serdev_controller_add(ctrl);
>> + if (ret)
>> + goto err;
>> +
>> + printk(KERN_INFO "serdev: Serial port %s\n", drv->name);
>
> Hmm... It's not a debug message, why not use pr_info()?
Converted to dev_info().
>> + 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.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
