From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935063AbdEWM2o (ORCPT ); Tue, 23 May 2017 08:28:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:32800 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752341AbdEWM2l (ORCPT ); Tue, 23 May 2017 08:28:41 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 15676239EB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=robh+dt@kernel.org MIME-Version: 1.0 In-Reply-To: <78B1501A-B9AD-4C6E-A481-26F647AA2BCE@goldelico.com> References: <78B1501A-B9AD-4C6E-A481-26F647AA2BCE@goldelico.com> From: Rob Herring Date: Tue, 23 May 2017 07:28:18 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC 0/3] misc: new serdev based drivers for w2sg00x4 GPS module and w2cbw003 wifi/bluetooth To: "H. Nikolaus Schaller" Cc: Mark Rutland , =?UTF-8?Q?Beno=C3=AEt_Cousson?= , Tony Lindgren , Russell King , Thierry Reding , Jonathan Cameron , Maxime Ripard , Jarkko Sakkinen , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-omap , Discussions about the Letux Kernel , kernel@pyra-handheld.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 23, 2017 at 12:43 AM, H. Nikolaus Schaller wrote: > Hi Rob, > >> Am 23.05.2017 um 04:26 schrieb Rob Herring : >> >> On Sun, May 21, 2017 at 5:44 AM, H. Nikolaus Schaller wrote: >>> Since our proposed API was not acceptable and the new serdev API has arrived in 4.11 kernels, >>> we finally took the challenge to update the w2sg and w2cbw drivers to use the serdev API. >>> >>> The approach is to write a "man in the middle" driver which is on one side a serdev client >>> which directly controls the UART where the device is connected to and on the other side >>> presents a new tty port so that user-space software can talk to the chips as if they would >>> directly talk to the UART of the SoC (e.g. ttyO1). This is similar to connecting to a remote >>> serial device e.g. through USB (ttyACM) or Bluetooth UART profiles. >>> >>> For example gpsd or hciattach expect a /dev/tty they can control (flow control, baud rate >>> etc.). >> >> I understand from the prior discussion why you want to pass the data >> thru for gps, but why do you need to do that for BT? > > Because we otherwise can't turn on power when /dev/ttyBT0 is opened and turn off when it > is closed. I.e. it should not be powered unless someone does a hciattach /dev/ttyBT0. And it > should be turned off by a killall hciattach. Still, you can do power control within BT HCI drivers. You wouldn't be limited to just open/close, but can handle suspend/resume as well. > Basically we would like to have a power control automatic like it exists for many other devices. > > Since the BT chip is described as a serdev by DT, we see no other means than to pass data > through the serdev driver. We could have a blacklist if we need to have serdev not create a device and create a tty device instead. > We had looked into the line discipline approach but it makes a lot of problems. The first one > is that registering a new system-wide ldesc number is required. Next we do not see how to make > a serdev driver (as it seems to be required by the DT) to register a different ldesc. > >> >>> Here is the result of our first hack which is working as a demo on GTA04 devices (and the >>> w2cbw driver can also be used to control a GTA04 variant with WL1837). >>> >>> Since it is just a demo hack, the code is not yet cleaned up, nor does it completely pass >>> check-patch, nor follows 100% the coding styles. And certainly has some bugs. >>> >>> The most significant issue is that calling tty_port_register_device() inside of the >>> serdev probe() function makes the serdev probe() function to be entered a second >>> time. This does not lead to big problems since we currently have minor = 0 >>> and this makes the second call assume the device is not available. >>> >>> But we have no idea why this happens and how it can be prevented. >> >> Johan's fixes may help there, but it is intended to be temporary to >> have a separate API for registering tty ports with or without serdev. > > Ah, would that mean something like a tty_port_register_device_without_serdev()? Yes, but other way around. The old function doesn't register with serdev and there's a new function that will. > Do you have a reference to his fixes? They are in Greg's tty-linus branch if not Linus' tree now. Rob