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: <20180326225106.GC1403@tuxbook-pro>
Date:   Tue, 27 Mar 2018 06:51:06 +0800
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Marcel Holtmann <marcel@...tmann.org>
Cc:     Thierry Escande <thierry.escande@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Andy Gross <andy.gross@...aro.org>,
        Johan Hedberg <johan.hedberg@...il.com>,
        David Brown <david.brown@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Loic Poulain <loic.poulain@...aro.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        linux-bluetooth@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        devicetree <devicetree@...r.kernel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 2/3] dt-bindings: net: bluetooth: Add
 qualcomm-bluetooth

On Tue 20 Mar 23:58 HKT 2018, Marcel Holtmann wrote:
> > Signed-off-by: Thierry Escande <thierry.escande@...aro.org>
[..]
> > + - clocks: clock phandle for SUSCLK_32KHZ
> 
> if I compare this with broadcom-bluetooth.txt or ti-bluetooth.txt then
> besides compatible, everything else is optional. The
> nokia-bluetooth.txt has everything required, but that is also a really
> specific platform.
> 
> Can we be less restrictive for a QCA general purpose chip?
> 

The way we deal with this in other bindings is that we tie such
requirements to the compatible; i.e. we would say that qcom,qca6174-bt
requires a clock and we would have something like qcom,qca-bt that makes
it optional.

The beauty of this is that the driver will tell you if you forgot to
specify the clock when it actually is required, which saves you
considerable amount of debugging time.


NB. The way the bcm driver handles this is insufficient, as it treats
any error from clk_get as "there's no clock specified". The driver
should accept a clock not being specified, but should fail properly when
a clock is specified but can't be acquired (e.g. due to clk_get()
returning EPROBE_DEFER).

> > +
> > +Example:
> > +
> > +serial@...0000 {
> > +	pinctrl-names = "default", "sleep";
> > +	pinctrl-0 = <&blsp1_uart1_default>;
> > +	pinctrl-1 = <&blsp1_uart1_sleep>;
> > +
> > +	bluetooth {
> > +		compatible = "qcom,qca6174-bt";
> > +
> > +		enable-gpios = <&pm8994_gpios 19 GPIO_ACTIVE_HIGH>;
> > +
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&bt_en_pin_a>;
> 
> This one I do not understand and you might want to shed some light
> into why this is done that way.
> 

This is completely generic and only relates to getting the electrical
properties of the gpio pin set up correctly. So I would recommend that
we omit this from the binding and example (including the pinctrl
properties for the serial above).

Regards,
Bjorn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ