[PATCH 2/3] clk: clk-cdce9xx.c: Change from u32 to ulong for addresses

[Tom Rini]

On Mon, Jul 14, 2025 at 12:35:14PM +0200, Quentin Schulz wrote:
> Hi Tom,
> 
> On 7/2/25 3:05 AM, Tom Rini wrote:
> > For 32/64bit correctness, we need to use ulong and not u32 for casting
> > for addresses.
> > 
> > Signed-off-by: Tom Rini <trini at konsulko.com>
> > ---
> > Cc: Lukasz Majewski <lukma at denx.de>
> > Cc: Sean Anderson <seanga2 at gmail.com>
> > ---
> >   drivers/clk/clk-cdce9xx.c | 10 +++++-----
> >   1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/clk/clk-cdce9xx.c b/drivers/clk/clk-cdce9xx.c
> > index e5f74e714d54..afb997c06be5 100644
> > --- a/drivers/clk/clk-cdce9xx.c
> > +++ b/drivers/clk/clk-cdce9xx.c
> > @@ -103,7 +103,7 @@ static int cdce9xx_clk_probe(struct udevice *dev)
> >   	u32 val;
> >   	struct clk clk;
> > -	val = (u32)dev_read_addr_ptr(dev);
> > +	val = (ulong)dev_read_addr_ptr(dev);
> 
> The output would be stored in a u32 anyway so not sure this actually helps
> (see type of val in the git context above).
> 
> >   	ret = i2c_get_chip(dev->parent, val, 1, &data->i2c);
> >   	if (ret) {
> > @@ -226,10 +226,10 @@ static ulong cdce9xx_clk_set_rate(struct clk *clk, ulong rate)
> >   }
> >   static const struct udevice_id cdce9xx_clk_of_match[] = {
> > -	{ .compatible = "ti,cdce913", .data = (u32)&cdce913_chip_info },
> > -	{ .compatible = "ti,cdce925", .data = (u32)&cdce925_chip_info },
> > -	{ .compatible = "ti,cdce937", .data = (u32)&cdce937_chip_info },
> > -	{ .compatible = "ti,cdce949", .data = (u32)&cdce949_chip_info },
> > +	{ .compatible = "ti,cdce913", .data = (ulong)&cdce913_chip_info },
> > +	{ .compatible = "ti,cdce925", .data = (ulong)&cdce925_chip_info },
> > +	{ .compatible = "ti,cdce937", .data = (ulong)&cdce937_chip_info },
> > +	{ .compatible = "ti,cdce949", .data = (ulong)&cdce949_chip_info },
> 
> Just get rid of the cast I guess? udevice_id.data being a ulong already the
> compiler should perform the cast in any case and this improves readability?

I'll take a harder look. This and maybe 1 or 3 other drivers are
following the above pattern. Thanks.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250714/49248794/attachment.sig>