linux-kernel - Re: [PATCH v5 4/4] Bluetooth: hci

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] [day] [month] [year] [list]

Message-Id: <139C4D84-3A51-4890-BD2F-995B4A6D57FC@holtmann.org>
Date:   Fri, 15 Nov 2019 09:04:52 +0100
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
Cc:     Johan Hedberg <johan.hedberg@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        linux-bluetooth@...r.kernel.org, dianders@...omium.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 4/4] Bluetooth: hci_bcm: Support pcm params in dts

Hi Abhishek,

> BCM chips may require configuration of PCM to operate correctly and
> there is a vendor specific HCI command to do this. Add support in the
> hci_bcm driver to parse this from devicetree and configure the chip.
> 
> Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
> ---
> Looks like hcitool cmd 0x3f 0x001d will read back the PCM parameters so
> I experimented with different values for sco_routing, interface_rate and
> other values.
> 
> The hardware doesn't care about frame_type, sync_mode or clock_mode (I
> put them all as 0, all as 1, etc). Only the sco_routing seems to have
> a discernable effect on the hardware.
> 
> To avoid complicating this, I opted not to read PCM settings and then
> write back to it. Let the user decide what to write themselves. I've
> opted to add a comment explaining that 0x001d is the read opcode if they
> want to verify it themselves.

actually I would really do it like this:

	1) read params
	2) overwrite values from DT
	2) write params (if transport mode is different)

The advantage with this is that when you have to debug things, then the btmon trace will contain the default values the firmware has. So it is in all trace files all the time. We do that with other parameters as for exactly that reason.

That also means you can drop has_pcm_params variable.

Regards

Marcel