lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <61301df80bd6a8ee0265b31b7f6a3aa1@codeaurora.org>
Date:   Thu, 10 Jan 2019 20:22:12 +0530
From:   Balakrishna Godavarthi <bgodavar@...eaurora.org>
To:     Johan Hovold <johan@...nel.org>
Cc:     marcel@...tmann.org, johan.hedberg@...il.com, mka@...omium.org,
        linux-kernel@...r.kernel.org, linux-bluetooth@...r.kernel.org,
        hemantg@...eaurora.org, linux-arm-msm@...r.kernel.org,
        Johan Hovold <jhovold@...il.com>
Subject: Re: [PATCH v5 2/5] Bluetooth: hci_qca: Deassert RTS while baudrate
 change command

Hi Johan,

On 2019-01-10 20:09, Johan Hovold wrote:
> On Thu, Jan 10, 2019 at 08:04:12PM +0530, Balakrishna Godavarthi wrote:
>> Hi Johan,
>> 
>> On 2019-01-09 20:22, Johan Hovold wrote:
>> > On Thu, Dec 20, 2018 at 08:16:36PM +0530, Balakrishna Godavarthi wrote:
>> >> This patch will help to stop frame reassembly errors while changing
>> >> the baudrate. This is because host send a change baudrate request
>> >> command to the chip with 115200 bps, Whereas chip will change their
>> >> UART clocks to the enable for new baudrate and sends the response
>> >> for the change request command with newer baudrate, On host side
>> >> we are still operating in 115200 bps which results of reading garbage
>> >> data. Here we are pulling RTS line, so that chip we will wait to send
>> >> data
>> >> to host until host change its baudrate.
> 
>> >> +		/* Deassert RTS while changing the baudrate of chip and host.
>> >> +		 * This will prevent chip from transmitting its response with
>> >> +		 * the new baudrate while the host port is still operating at
>> >> +		 * the old speed.
>> >> +		 */
>> >> +		qcadev = serdev_device_get_drvdata(hu->serdev);
>> >> +		if (qcadev->btsoc_type == QCA_WCN3990)
>> >> +			serdev_device_set_rts(hu->serdev, false);
>> >> +
>> >
>> > This may not do what you want unless you also disable hardware flow
>> > control.
> 
>> Here my requirement here is to block the chip to send its data before
>> HOST changes it is baudrate. So if i disable flow control lines of
>> HOST which will be in low state.  so that the chip will send it data
>> before HOST change the baudrate of HOST. which results in frame
>> reassembly error.
> 
> Not sure I understand what you're trying to say above. My point is that
> you cannot reliable control RTS when you have automatic flow control
> enabled (i.e. it is managed by hardware and it's state reflects whether
> there's room in the UART receive FIFO).
> 
> Johan

[Bala]: Yes i got your point, but our driver will not support automatic 
flow control (based on the FIFO status)
         unless we explicitly enabled via software. i.e. if we enable the 
flow, hardware will look for it.
         else it will not looks for CTS or RTS Line.

-- 
Regards
Balakrishna.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ