All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: "lee.jones@linaro.org" <lee.jones@linaro.org>
Cc: "linux@roeck-us.net" <linux@roeck-us.net>,
	"wim@linux-watchdog.org" <wim@linux-watchdog.org>,
	"mazziesaccount@gmail.com" <mazziesaccount@gmail.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	linux-power <linux-power@fi.rohmeurope.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>
Subject: Re: [PATCH v4 2/4] mfd: Support ROHM BD9576MUF and BD9573MUF
Date: Thu, 5 Nov 2020 06:46:12 +0000	[thread overview]
Message-ID: <058913084af32743f2e23228a46944bbfcbd52d2.camel@fi.rohmeurope.com> (raw)
In-Reply-To: <20201104155153.GQ4488@dell>

Morning Lee,

Thanks for taking a look at this :) I see most of the comments being
valid. There's two I would like to clarify though...

On Wed, 2020-11-04 at 15:51 +0000, Lee Jones wrote:
> On Wed, 28 Oct 2020, Matti Vaittinen wrote:
> 
> > Add core support for ROHM BD9576MUF and BD9573MUF PMICs which are
> > mainly used to power the R-Car series processors.
> > 
> > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> > ---
> > +	unsigned int chip_type;
> > +
> > +	chip_type = (unsigned int)(uintptr_t)
> > +		    of_device_get_match_data(&i2c->dev);
> 
> Not overly keen on this casting.
> 
> Why not just leave it as (uintptr_t)?

I didn't do so because on x86_64 the address width is probably 64 bits
whereas the unsigned int is likely to be 32 bits. So the assignment
will crop half of the value. It does not really matter as values are
small - but I would be surprized if no compilers/analyzers emitted a
warning.

I must admit I am not 100% sure though. I sure can change this if you
know it better?

> What happens when you don't cast to (uintptr_t) first?

On some systems at least the gcc will warn:
> warning: cast from pointer to integer of different size [-Wpointer-
to-int-cast]

I am pretty sure I did end up this double casting via trial and error
:)
+
> > +static const struct of_device_id bd957x_of_match[] = {
> > +	{
> > +		.compatible = "rohm,bd9576",
> > +		.data = (void *)ROHM_CHIP_TYPE_BD9576,
> > +	},
> > +	{
> 
> You could put the 2 lines above on a single line.

Braces? I put braces on separate lines on purpose. Been doing this
after we had this discussion:

https://lore.kernel.org/lkml/20180705055226.GJ496@dell/
https://lore.kernel.org/lkml/20180706070559.GW496@dell/

;)

I can change it if you wishfeel it is important - not a point I feel
like fighting over ;)

> 
> > +		.compatible = "rohm,bd9573",
> > +		.data = (void *)ROHM_CHIP_TYPE_BD9573,
> > +	},
> > +	{ },
> > +};
> > +MODULE_DEVICE_TABLE(of, bd957x_of_match);


Best Regards
	Matti

--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland
SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~

Simon says - in Latin please.
"non cogito me" dixit Rene Descarte, deinde evanescavit

(Thanks for the translation Simon)


  reply	other threads:[~2020-11-05  6:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-28  9:45 [PATCH v4 0/4] Support ROHM BD9576MUF and BD9573MUF PMICs Matti Vaittinen
2020-10-28  9:46 ` [PATCH v4 1/4] dt_bindings: mfd: Add " Matti Vaittinen
2020-10-28  9:46 ` [PATCH v4 2/4] mfd: Support ROHM BD9576MUF and BD9573MUF Matti Vaittinen
2020-11-04 15:51   ` Lee Jones
2020-11-05  6:46     ` Vaittinen, Matti [this message]
2020-11-05  7:40       ` Vaittinen, Matti
2020-11-05  8:21         ` Lee Jones
2020-11-05  8:56           ` Vaittinen, Matti
2020-11-05  8:58             ` Lee Jones
2020-11-05 10:00               ` Vaittinen, Matti
2020-11-05  8:23     ` Lee Jones
2020-11-05  8:58       ` Vaittinen, Matti
2020-10-28  9:48 ` [PATCH v4 3/4] wdt: Support wdt on " Matti Vaittinen
2020-10-28  9:49 ` [PATCH v4 4/4] MAINTAINERS: Add ROHM BD9576MUF and BD9573MUF drivers Matti Vaittinen

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=058913084af32743f2e23228a46944bbfcbd52d2.camel@fi.rohmeurope.com \
    --to=matti.vaittinen@fi.rohmeurope.com \
    --cc=devicetree@vger.kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-power@fi.rohmeurope.com \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mazziesaccount@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=wim@linux-watchdog.org \
    /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.