From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Niklas Cassel <cassel@kernel.org>
Cc: "Yury Norov" <yury.norov@gmail.com>,
"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
"Jaehoon Chung" <jh80.chung@samsung.com>,
"Ulf Hansson" <ulf.hansson@linaro.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Shreeya Patel" <shreeya.patel@collabora.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Sandy Huang" <hjc@rock-chips.com>,
"Andy Yan" <andy.yan@rock-chips.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Vinod Koul" <vkoul@kernel.org>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Nicolas Frattaroli" <frattaroli.nicolas@gmail.com>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Mark Brown" <broonie@kernel.org>,
"Jaroslav Kysela" <perex@perex.cz>,
"Takashi Iwai" <tiwai@suse.com>,
"Andrew Lunn" <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
"Shawn Lin" <shawn.lin@rock-chips.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Chanwoo Choi" <cw00.choi@samsung.com>,
"MyungJoo Ham" <myungjoo.ham@samsung.com>,
"Kyungmin Park" <kyungmin.park@samsung.com>,
"Qin Jian" <qinjian@cqplus1.com>,
"Michael Turquette" <mturquette@baylibre.com>,
"Stephen Boyd" <sboyd@kernel.org>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nick Desaulniers" <nick.desaulniers+lkml@gmail.com>,
"Bill Wendling" <morbo@google.com>,
"Justin Stitt" <justinstitt@google.com>,
kernel@collabora.com, linux-kernel@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-media@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-phy@lists.infradead.org,
linux-sound@vger.kernel.org, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-pci@vger.kernel.org, linux-pm@vger.kernel.org,
linux-clk@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH 17/20] PCI: dw-rockchip: switch to HWORD_UPDATE macro
Date: Fri, 13 Jun 2025 14:08:08 +0200 [thread overview]
Message-ID: <12129790.nUPlyArG6x@workhorse> (raw)
In-Reply-To: <aEvzMnxgsjfryCOo@ryzen>
Hello,
On Friday, 13 June 2025 11:45:22 Central European Summer Time Niklas Cassel wrote:
> Hello Nicolas,
>
> On Thu, Jun 12, 2025 at 08:56:19PM +0200, Nicolas Frattaroli wrote:
> >
> > PCIE_CLIENT_RC_MODE/PCIE_CLIENT_EP_MODE was another field that wasn't
> > super clear on what the bit field modification actually is. As far as I
> > can tell, switching to RC mode doesn't actually write the correct value
> > to the field if any of its bits have been set previously, as it only
> > updates one bit of a 4 bit field.
> >
> > Replace it by actually writing the full values to the field, using the
> > new HWORD_UPDATE macro, which grants us the benefit of better
> > compile-time error checking.
>
> The current code looks like this:
> #define PCIE_CLIENT_RC_MODE HIWORD_UPDATE_BIT(0x40)
> #define PCIE_CLIENT_EP_MODE HIWORD_UPDATE(0xf0, 0x0)
>
> The device_type field is defined like this:
> 4'h0: PCI Express endpoint
> 4'h1: Legacy PCI Express endpoint
> 4'h4: Root port of PCI Express root complex
>
> The reset value of the device_type field is 0x0 (EP mode).
>
> So switching between RC mode / EP mode should be fine.
>
> But I agree, theoretically there could be a bug if e.g. bootloader
> has set the device_type to 0x1 (Legacy EP).
>
> So if you want, you could send a patch:
> -#define PCIE_CLIENT_RC_MODE HIWORD_UPDATE_BIT(0x40)
> +#define PCIE_CLIENT_RC_MODE HIWORD_UPDATE(0xf0, 0x40)
>
> With:
> Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver")
>
> But I also think that your current patch is fine as-is.
>
> I do however think that you can drop this line:
> +#define PCIE_CLIENT_MODE_LEGACY 0x1U
>
> Since the define is never used.
Will do
>
>
> Also, is there any point in adding the U suffix?
>
> Usually you see UL or ULL suffix, when that is needed, but there actually
> seems to be extremely few hits of simply U suffix:
> $ git grep 0x1U | grep -v UL
Sort of. Literals without the U suffix are considered signed iirc, and
operating with them and then left-shifting the result can run into issues
if you shift their bits into the sign bit. In the patch at [1] I needed to
quell a compiler warning about signed long overflows with a U suffix. This
should only ever really be a problem for anything that gets shifted up to
bit index 31 I believe, and maybe there's a better way to handle this in
the macro itself with an explicit cast to unsigned, but explicit casts
give me the ick. I'm also open to changing it to an UL, which will have
the same effect, and has more precedent.
>
>
> Kind regards,
> Niklas
>
Best Regards,
Nicolas Frattaroli
Link: https://lore.kernel.org/all/20250612-byeword-update-v1-7-f4afb8f6313f@collabora.com/ [1]
next prev parent reply other threads:[~2025-06-13 12:09 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-12 18:56 [PATCH 00/20] BYEWORD_UPDATE: unifying (most) HIWORD_UPDATE macros Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 01/20] bitfield: introduce HWORD_UPDATE bitfield macros Nicolas Frattaroli
2025-06-12 19:44 ` Jakub Kicinski
2025-06-12 19:50 ` Nicolas Frattaroli
2025-06-12 20:10 ` Yury Norov
2025-06-12 22:01 ` Jakub Kicinski
2025-06-13 8:51 ` Jani Nikula
2025-06-13 11:55 ` Nicolas Frattaroli
2025-06-13 12:28 ` Yury Norov
2025-06-13 14:59 ` Jakub Kicinski
2025-06-13 13:54 ` Robin Murphy
2025-06-13 14:52 ` Yury Norov
2025-06-16 12:27 ` Nicolas Frattaroli
2025-06-16 13:26 ` Jani Nikula
2025-06-12 18:56 ` [PATCH 02/20] mmc: dw_mmc-rockchip: switch to HWORD_UPDATE macro Nicolas Frattaroli
2025-06-16 13:29 ` Ulf Hansson
2025-06-12 18:56 ` [PATCH 03/20] soc: rockchip: grf: switch to HWORD_UPDATE_CONST macro Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 04/20] media: synopsys: hdmirx: replace macros with bitfield variants Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 05/20] drm/rockchip: lvds: switch to HWORD_UPDATE macro Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 06/20] phy: rockchip-emmc: " Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 07/20] drm/rockchip: dsi: switch to HWORD_UPDATE* macros Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 08/20] drm/rockchip: vop2: switch to HWORD_UPDATE macro Nicolas Frattaroli
2025-06-13 9:55 ` Cristian Ciocaltea
2025-06-12 18:56 ` [PATCH 09/20] phy: rockchip-samsung-dcphy: " Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 10/20] drm/rockchip: dw_hdmi_qp: " Nicolas Frattaroli
2025-06-13 10:08 ` Cristian Ciocaltea
2025-06-12 18:56 ` [PATCH 11/20] drm/rockchip: inno-hdmi: " Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 12/20] phy: rockchip-usb: " Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 13/20] drm/rockchip: dw_hdmi: switch to HWORD_UPDATE* macros Nicolas Frattaroli
2025-06-13 10:15 ` Cristian Ciocaltea
2025-06-12 18:56 ` [PATCH 14/20] ASoC: rockchip: i2s-tdm: switch to HWORD_UPDATE_CONST macro Nicolas Frattaroli
2025-06-13 11:12 ` Mark Brown
2025-06-12 18:56 ` [PATCH 15/20] net: stmmac: dwmac-rk: switch to HWORD_UPDATE macro Nicolas Frattaroli
2025-06-12 19:08 ` Andrew Lunn
2025-06-12 19:16 ` Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 16/20] PCI: rockchip: switch to HWORD_UPDATE* macros Nicolas Frattaroli
2025-06-12 19:37 ` Bjorn Helgaas
2025-06-12 19:52 ` Yury Norov
2025-06-12 18:56 ` [PATCH 17/20] PCI: dw-rockchip: switch to HWORD_UPDATE macro Nicolas Frattaroli
2025-06-12 19:38 ` Bjorn Helgaas
2025-06-13 9:45 ` Niklas Cassel
2025-06-13 12:08 ` Nicolas Frattaroli [this message]
2025-06-12 18:56 ` [PATCH 18/20] PM / devfreq: rockchip-dfi: " Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 19/20] clk: sp7021: " Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 20/20] phy: rockchip-pcie: " Nicolas Frattaroli
2025-06-12 19:45 ` [PATCH 00/20] BYEWORD_UPDATE: unifying (most) HIWORD_UPDATE macros Yury Norov
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=12129790.nUPlyArG6x@workhorse \
--to=nicolas.frattaroli@collabora.com \
--cc=airlied@gmail.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=andy.yan@rock-chips.com \
--cc=bhelgaas@google.com \
--cc=broonie@kernel.org \
--cc=cassel@kernel.org \
--cc=cw00.choi@samsung.com \
--cc=davem@davemloft.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=edumazet@google.com \
--cc=frattaroli.nicolas@gmail.com \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=jh80.chung@samsung.com \
--cc=justinstitt@google.com \
--cc=kernel@collabora.com \
--cc=kishon@kernel.org \
--cc=kuba@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=kyungmin.park@samsung.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-sound@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux@rasmusvillemoes.dk \
--cc=llvm@lists.linux.dev \
--cc=lpieralisi@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mani@kernel.org \
--cc=mchehab@kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=morbo@google.com \
--cc=mripard@kernel.org \
--cc=mturquette@baylibre.com \
--cc=myungjoo.ham@samsung.com \
--cc=nathan@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=pabeni@redhat.com \
--cc=perex@perex.cz \
--cc=qinjian@cqplus1.com \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=shawn.lin@rock-chips.com \
--cc=shreeya.patel@collabora.com \
--cc=simona@ffwll.ch \
--cc=tiwai@suse.com \
--cc=tzimmermann@suse.de \
--cc=ulf.hansson@linaro.org \
--cc=vkoul@kernel.org \
--cc=yury.norov@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).