From: Vinod Koul <vkoul@kernel.org>
To: Peter Geis <pgwipeout@gmail.com>
Cc: Yifeng Zhao <yifeng.zhao@rock-chips.com>,
Heiko Stuebner <heiko@sntech.de>,
Rob Herring <robh+dt@kernel.org>,
devicetree <devicetree@vger.kernel.org>,
Michael Riesch <michael.riesch@wolfvision.net>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
arm-mail-list <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-phy@lists.infradead.org, "Kishon Vijay Abraham,
I" <kishon@ti.com>,
p.zabel@pengutronix.de
Subject: Re: [PATCH v2 2/3] phy/rockchip: add naneng combo phy for RK3568
Date: Mon, 25 Oct 2021 12:36:52 +0530 [thread overview]
Message-ID: <YXZXjGG1qpHCgdHc@matsya> (raw)
In-Reply-To: <CAMdYzYqJs_uT1DT9EFydAmWCoRuizkA==HoMW8VTd68dg0hQ2A@mail.gmail.com>
On 22-10-21, 07:26, Peter Geis wrote:
> On Fri, Oct 22, 2021 at 6:51 AM Vinod Koul <vkoul@kernel.org> wrote:
> > On 13-10-21, 18:19, Yifeng Zhao wrote:
> > > +#define RK3568_T22_PHYREG6 (0x6 << 2)
> > > +#define T22_PHYREG6_TX_RTERM_MASK GENMASK(7, 4)
> > > +#define T22_PHYREG6_TX_RTERM_SHIFT 4
> > > +#define T22_PHYREG6_TX_RTERM_50OHM 0x8
> > > +#define T22_PHYREG6_RX_RTERM_MASK GENMASK(3, 0)
> > > +#define T22_PHYREG6_RX_RTERM_SHIFT 0
> > > +#define T22_PHYREG6_RX_RTERM_44OHM 0xF
> > > +
> > > +#define RK3568_T22_PHYREG7 (0x7 << 2)
> >
> > Pls use GENMASK for these?
> >
> > > +#define T22_PHYREG7_SSC_EN BIT(4)
> > > +
> > > +#define RK3568_T22_PHYREG10 (0xA << 2)
> > > +#define T22_PHYREG10_SU_TRIM_0_7 0xF0
> > > +
> > > +#define RK3568_T22_PHYREG11 (0xB << 2)
> > > +#define T22_PHYREG11_PLL_LPF_ADJ 0x4
> > > +
> > > +#define RK3568_T22_PHYREG12 (0xC << 2)
> > > +#define T22_PHYREG12_RESISTER_MASK GENMASK(5, 4)
> > > +#define T22_PHYREG12_RESISTER_SHIFT 0x4
> >
> > bitfield.h has nice helpers which can extract/program values and avoid
> > one to define these shifts
>
> They aren't values, they are registers.
Yes!
> This is a remnant from the downstream driver's attempt at obfuscating
> the register it's touching.
> Please define these correctly.
The point of bitfield.h is one defines register bit fields using
BIT/GENMASK, no need to define SHIFT etc and use the helpers to
extract/program values and avoid defining these shifts etc!
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vkoul@kernel.org>
To: Peter Geis <pgwipeout@gmail.com>
Cc: Yifeng Zhao <yifeng.zhao@rock-chips.com>,
Heiko Stuebner <heiko@sntech.de>,
Rob Herring <robh+dt@kernel.org>,
devicetree <devicetree@vger.kernel.org>,
Michael Riesch <michael.riesch@wolfvision.net>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
arm-mail-list <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-phy@lists.infradead.org, "Kishon Vijay Abraham,
I" <kishon@ti.com>,
p.zabel@pengutronix.de
Subject: Re: [PATCH v2 2/3] phy/rockchip: add naneng combo phy for RK3568
Date: Mon, 25 Oct 2021 12:36:52 +0530 [thread overview]
Message-ID: <YXZXjGG1qpHCgdHc@matsya> (raw)
In-Reply-To: <CAMdYzYqJs_uT1DT9EFydAmWCoRuizkA==HoMW8VTd68dg0hQ2A@mail.gmail.com>
On 22-10-21, 07:26, Peter Geis wrote:
> On Fri, Oct 22, 2021 at 6:51 AM Vinod Koul <vkoul@kernel.org> wrote:
> > On 13-10-21, 18:19, Yifeng Zhao wrote:
> > > +#define RK3568_T22_PHYREG6 (0x6 << 2)
> > > +#define T22_PHYREG6_TX_RTERM_MASK GENMASK(7, 4)
> > > +#define T22_PHYREG6_TX_RTERM_SHIFT 4
> > > +#define T22_PHYREG6_TX_RTERM_50OHM 0x8
> > > +#define T22_PHYREG6_RX_RTERM_MASK GENMASK(3, 0)
> > > +#define T22_PHYREG6_RX_RTERM_SHIFT 0
> > > +#define T22_PHYREG6_RX_RTERM_44OHM 0xF
> > > +
> > > +#define RK3568_T22_PHYREG7 (0x7 << 2)
> >
> > Pls use GENMASK for these?
> >
> > > +#define T22_PHYREG7_SSC_EN BIT(4)
> > > +
> > > +#define RK3568_T22_PHYREG10 (0xA << 2)
> > > +#define T22_PHYREG10_SU_TRIM_0_7 0xF0
> > > +
> > > +#define RK3568_T22_PHYREG11 (0xB << 2)
> > > +#define T22_PHYREG11_PLL_LPF_ADJ 0x4
> > > +
> > > +#define RK3568_T22_PHYREG12 (0xC << 2)
> > > +#define T22_PHYREG12_RESISTER_MASK GENMASK(5, 4)
> > > +#define T22_PHYREG12_RESISTER_SHIFT 0x4
> >
> > bitfield.h has nice helpers which can extract/program values and avoid
> > one to define these shifts
>
> They aren't values, they are registers.
Yes!
> This is a remnant from the downstream driver's attempt at obfuscating
> the register it's touching.
> Please define these correctly.
The point of bitfield.h is one defines register bit fields using
BIT/GENMASK, no need to define SHIFT etc and use the helpers to
extract/program values and avoid defining these shifts etc!
--
~Vinod
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vkoul@kernel.org>
To: Peter Geis <pgwipeout@gmail.com>
Cc: Yifeng Zhao <yifeng.zhao@rock-chips.com>,
Heiko Stuebner <heiko@sntech.de>,
Rob Herring <robh+dt@kernel.org>,
devicetree <devicetree@vger.kernel.org>,
Michael Riesch <michael.riesch@wolfvision.net>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
arm-mail-list <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-phy@lists.infradead.org, "Kishon Vijay Abraham,
I" <kishon@ti.com>,
p.zabel@pengutronix.de
Subject: Re: [PATCH v2 2/3] phy/rockchip: add naneng combo phy for RK3568
Date: Mon, 25 Oct 2021 12:36:52 +0530 [thread overview]
Message-ID: <YXZXjGG1qpHCgdHc@matsya> (raw)
In-Reply-To: <CAMdYzYqJs_uT1DT9EFydAmWCoRuizkA==HoMW8VTd68dg0hQ2A@mail.gmail.com>
On 22-10-21, 07:26, Peter Geis wrote:
> On Fri, Oct 22, 2021 at 6:51 AM Vinod Koul <vkoul@kernel.org> wrote:
> > On 13-10-21, 18:19, Yifeng Zhao wrote:
> > > +#define RK3568_T22_PHYREG6 (0x6 << 2)
> > > +#define T22_PHYREG6_TX_RTERM_MASK GENMASK(7, 4)
> > > +#define T22_PHYREG6_TX_RTERM_SHIFT 4
> > > +#define T22_PHYREG6_TX_RTERM_50OHM 0x8
> > > +#define T22_PHYREG6_RX_RTERM_MASK GENMASK(3, 0)
> > > +#define T22_PHYREG6_RX_RTERM_SHIFT 0
> > > +#define T22_PHYREG6_RX_RTERM_44OHM 0xF
> > > +
> > > +#define RK3568_T22_PHYREG7 (0x7 << 2)
> >
> > Pls use GENMASK for these?
> >
> > > +#define T22_PHYREG7_SSC_EN BIT(4)
> > > +
> > > +#define RK3568_T22_PHYREG10 (0xA << 2)
> > > +#define T22_PHYREG10_SU_TRIM_0_7 0xF0
> > > +
> > > +#define RK3568_T22_PHYREG11 (0xB << 2)
> > > +#define T22_PHYREG11_PLL_LPF_ADJ 0x4
> > > +
> > > +#define RK3568_T22_PHYREG12 (0xC << 2)
> > > +#define T22_PHYREG12_RESISTER_MASK GENMASK(5, 4)
> > > +#define T22_PHYREG12_RESISTER_SHIFT 0x4
> >
> > bitfield.h has nice helpers which can extract/program values and avoid
> > one to define these shifts
>
> They aren't values, they are registers.
Yes!
> This is a remnant from the downstream driver's attempt at obfuscating
> the register it's touching.
> Please define these correctly.
The point of bitfield.h is one defines register bit fields using
BIT/GENMASK, no need to define SHIFT etc and use the helpers to
extract/program values and avoid defining these shifts etc!
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vkoul@kernel.org>
To: Peter Geis <pgwipeout@gmail.com>
Cc: Yifeng Zhao <yifeng.zhao@rock-chips.com>,
Heiko Stuebner <heiko@sntech.de>,
Rob Herring <robh+dt@kernel.org>,
devicetree <devicetree@vger.kernel.org>,
Michael Riesch <michael.riesch@wolfvision.net>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
arm-mail-list <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-phy@lists.infradead.org, "Kishon Vijay Abraham,
I" <kishon@ti.com>,
p.zabel@pengutronix.de
Subject: Re: [PATCH v2 2/3] phy/rockchip: add naneng combo phy for RK3568
Date: Mon, 25 Oct 2021 12:36:52 +0530 [thread overview]
Message-ID: <YXZXjGG1qpHCgdHc@matsya> (raw)
In-Reply-To: <CAMdYzYqJs_uT1DT9EFydAmWCoRuizkA==HoMW8VTd68dg0hQ2A@mail.gmail.com>
On 22-10-21, 07:26, Peter Geis wrote:
> On Fri, Oct 22, 2021 at 6:51 AM Vinod Koul <vkoul@kernel.org> wrote:
> > On 13-10-21, 18:19, Yifeng Zhao wrote:
> > > +#define RK3568_T22_PHYREG6 (0x6 << 2)
> > > +#define T22_PHYREG6_TX_RTERM_MASK GENMASK(7, 4)
> > > +#define T22_PHYREG6_TX_RTERM_SHIFT 4
> > > +#define T22_PHYREG6_TX_RTERM_50OHM 0x8
> > > +#define T22_PHYREG6_RX_RTERM_MASK GENMASK(3, 0)
> > > +#define T22_PHYREG6_RX_RTERM_SHIFT 0
> > > +#define T22_PHYREG6_RX_RTERM_44OHM 0xF
> > > +
> > > +#define RK3568_T22_PHYREG7 (0x7 << 2)
> >
> > Pls use GENMASK for these?
> >
> > > +#define T22_PHYREG7_SSC_EN BIT(4)
> > > +
> > > +#define RK3568_T22_PHYREG10 (0xA << 2)
> > > +#define T22_PHYREG10_SU_TRIM_0_7 0xF0
> > > +
> > > +#define RK3568_T22_PHYREG11 (0xB << 2)
> > > +#define T22_PHYREG11_PLL_LPF_ADJ 0x4
> > > +
> > > +#define RK3568_T22_PHYREG12 (0xC << 2)
> > > +#define T22_PHYREG12_RESISTER_MASK GENMASK(5, 4)
> > > +#define T22_PHYREG12_RESISTER_SHIFT 0x4
> >
> > bitfield.h has nice helpers which can extract/program values and avoid
> > one to define these shifts
>
> They aren't values, they are registers.
Yes!
> This is a remnant from the downstream driver's attempt at obfuscating
> the register it's touching.
> Please define these correctly.
The point of bitfield.h is one defines register bit fields using
BIT/GENMASK, no need to define SHIFT etc and use the helpers to
extract/program values and avoid defining these shifts etc!
--
~Vinod
next prev parent reply other threads:[~2021-10-25 7:17 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-13 10:19 [PATCH v2 0/3] Add Naneng combo PHY support for RK3568 Yifeng Zhao
2021-10-13 10:19 ` Yifeng Zhao
2021-10-13 10:19 ` Yifeng Zhao
2021-10-13 10:19 ` Yifeng Zhao
2021-10-13 10:19 ` [PATCH v2 1/3] dt-bindings: phy: rockchip: Add Naneng combo PHY bindings Yifeng Zhao
2021-10-13 10:19 ` Yifeng Zhao
2021-10-13 10:19 ` Yifeng Zhao
2021-10-13 10:19 ` Yifeng Zhao
2021-10-25 7:07 ` Vinod Koul
2021-10-25 7:07 ` Vinod Koul
2021-10-25 7:07 ` Vinod Koul
2021-10-25 7:07 ` Vinod Koul
2021-10-13 10:19 ` [PATCH v2 2/3] phy/rockchip: add naneng combo phy for RK3568 Yifeng Zhao
2021-10-13 10:19 ` Yifeng Zhao
2021-10-13 10:19 ` Yifeng Zhao
2021-10-13 10:19 ` Yifeng Zhao
2021-10-14 11:37 ` Philipp Zabel
2021-10-14 11:37 ` Philipp Zabel
2021-10-14 11:37 ` Philipp Zabel
2021-10-14 11:37 ` Philipp Zabel
2021-10-22 10:49 ` Vinod Koul
2021-10-22 10:49 ` Vinod Koul
2021-10-22 10:49 ` Vinod Koul
2021-10-22 10:49 ` Vinod Koul
2021-10-22 11:26 ` Peter Geis
2021-10-22 11:26 ` Peter Geis
2021-10-22 11:26 ` Peter Geis
2021-10-22 11:26 ` Peter Geis
2021-10-25 7:06 ` Vinod Koul [this message]
2021-10-25 7:06 ` Vinod Koul
2021-10-25 7:06 ` Vinod Koul
2021-10-25 7:06 ` Vinod Koul
2021-10-13 10:19 ` [PATCH v2 3/3] arm64: dts: rockchip: add naneng combo phy nodes for rk3568 Yifeng Zhao
2021-10-13 10:19 ` Yifeng Zhao
2021-10-13 10:19 ` Yifeng Zhao
2021-10-13 10:19 ` Yifeng Zhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YXZXjGG1qpHCgdHc@matsya \
--to=vkoul@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=michael.riesch@wolfvision.net \
--cc=p.zabel@pengutronix.de \
--cc=pgwipeout@gmail.com \
--cc=robh+dt@kernel.org \
--cc=yifeng.zhao@rock-chips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.