On Mon, Jan 21, 2019 at 09:56:13AM +0100, Johan Hovold wrote: > On Fri, Jan 18, 2019 at 04:31:09PM -0800, Matthias Kaehlcke wrote: > > On Fri, Jan 18, 2019 at 10:44:16AM +0100, Johan Hovold wrote: > > > On Thu, Jan 17, 2019 at 09:21:09AM -0800, Matthias Kaehlcke wrote: > > > > > > > I observed that the qcom_geni_serial driver doesn't raise RTS with > > > > flow control disabled. It seems we have to investigate why that's the > > > > case. I agree that the driver should be platform agnostic. > > > > > > Sounds like a driver bug, unless the hardware is just "odd". The > > > driver implementation of this looks very non-standard judging from a > > > quick peek. > > > > > > In fact, qcom_geni_serial_get_mctrl() is currently a no-op if hardware > > > flow control is not enabled: > > > > > > if (uart_console(uport) || !uart_cts_enabled(uport)) > > > return; > > > > > > Perhaps dropping the !uart_cts_enabled() test is sufficient. > > > > Thanks for taking a look Johan, that was indeed the problem (also > > in set_mctrl()). I posted a fix: https://lore.kernel.org/patchwork/patch/1033611/ > > Nice (I did mean set_mctrl() above, as I think you noticed). > > > Balakrishna, the following (applied on top of your patch) works for me > > with the UART patch above: > > > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c > > index 9d5e41f159c78f..60bfdf01f72841 100644 > > --- a/drivers/bluetooth/hci_qca.c > > +++ b/drivers/bluetooth/hci_qca.c > > @@ -1080,7 +1080,7 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type) > > { > > unsigned int speed, qca_baudrate; > > struct qca_serdev *qcadev; > > - int ret; > > + int ret = 0; > > > > if (speed_type == QCA_INIT_SPEED) { > > speed = qca_get_speed(hu, QCA_INIT_SPEED); > > @@ -1097,22 +1097,27 @@ static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type) > > * the old speed. > > */ > > qcadev = serdev_device_get_drvdata(hu->serdev); > > - if (qcadev->btsoc_type == QCA_WCN3990) > > + if (qcadev->btsoc_type == QCA_WCN3990) { > > + hci_uart_set_flow_control(hu, true); > > Wow, yeah, this parameter inversion is indeed confusing... > > > serdev_device_set_rts(hu->serdev, false); > > + } > > But looking at hci_uart_set_flow_control() now, it actually also > deasserts RTS. So all you need here is the hci_uart_set_flow_control() > call. Great, thanks for pointing that out! > And that makes the inversion make a bit more sense too, even if the > naming is a bit unfortunate with respect to > serdev_device_set_flow_control() at least.
