linux-kernel - Re: [net-next RFC PATCH 11/14] dt-bindings: net: add QCA807x PHY defines

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]

Date:   Thu, 23 Nov 2023 04:01:41 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Christian Marangi <ansuelsmth@...il.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Florian Fainelli <florian.fainelli@...adcom.com>,
        Broadcom internal kernel review list 
        <bcm-kernel-feedback-list@...adcom.com>,
        Daniel Golle <daniel@...rotopia.org>,
        Qingfang Deng <dqfext@...il.com>,
        SkyLake Huang <SkyLake.Huang@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        David Epping <david.epping@...singlinkelectronics.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
        Harini Katakam <harini.katakam@....com>,
        Simon Horman <horms@...nel.org>,
        Robert Marko <robert.marko@...tura.hr>, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org
Subject: Re: [net-next RFC PATCH 11/14] dt-bindings: net: add QCA807x PHY
 defines

On Mon, Nov 20, 2023 at 02:50:38PM +0100, Christian Marangi wrote:
> From: Robert Marko <robert.marko@...tura.hr>
> 
> Add DT bindings defined for Qualcomm QCA807x PHY series related to
> calibration and DAC settings.
> 
> Signed-off-by: Robert Marko <robert.marko@...tura.hr>
> Signed-off-by: Christian Marangi <ansuelsmth@...il.com>
> ---
>  include/dt-bindings/net/qcom-qca807x.h | 45 ++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 include/dt-bindings/net/qcom-qca807x.h
> 
> diff --git a/include/dt-bindings/net/qcom-qca807x.h b/include/dt-bindings/net/qcom-qca807x.h
> new file mode 100644
> index 000000000000..42c45c7d5210
> --- /dev/null
> +++ b/include/dt-bindings/net/qcom-qca807x.h
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
> +/*
> + * Device Tree constants for the Qualcomm QCA807X PHYs
> + */
> +
> +#ifndef _DT_BINDINGS_QCOM_QCA807X_H
> +#define _DT_BINDINGS_QCOM_QCA807X_H
> +
> +#define PSGMII_QSGMII_TX_DRIVER_140MV	0
> +#define PSGMII_QSGMII_TX_DRIVER_160MV	1
> +#define PSGMII_QSGMII_TX_DRIVER_180MV	2
> +#define PSGMII_QSGMII_TX_DRIVER_200MV	3
> +#define PSGMII_QSGMII_TX_DRIVER_220MV	4
> +#define PSGMII_QSGMII_TX_DRIVER_240MV	5
> +#define PSGMII_QSGMII_TX_DRIVER_260MV	6
> +#define PSGMII_QSGMII_TX_DRIVER_280MV	7
> +#define PSGMII_QSGMII_TX_DRIVER_300MV	8
> +#define PSGMII_QSGMII_TX_DRIVER_320MV	9
> +#define PSGMII_QSGMII_TX_DRIVER_400MV	10
> +#define PSGMII_QSGMII_TX_DRIVER_500MV	11
> +/* Default value */
> +#define PSGMII_QSGMII_TX_DRIVER_600MV	12

Its not clear what these are used for. I think these are actually
package properties, so having the correctly documented in the binding
would help a lot understand why we need package properties.

Actually using #define like this is probably wrong. You should just
have a u32 tx_driver_mv property, and list [140, 160, 180, 200,
... 600] as valid values. The driver should then convert to whatever
value it should write into the register.

      Andrew