Re: [PATCH v2 8/8] rtc: isl12022: implement support for the #clock-cells DT property

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 14, 2023 at 12:51:47PM +0200, Rasmus Villemoes wrote:
> On 13/06/2023 17.25, Andy Shevchenko wrote:
> > On Tue, Jun 13, 2023 at 03:00:10PM +0200, Rasmus Villemoes wrote:

...

> >> +#define ISL12022_INT_FO_MASK	GENMASK(3, 0)
> >> +#define ISL12022_INT_FO_OFF	0x0
> >> +#define ISL12022_INT_FO_32K	0x1
> > 
> > A nit-pick. Are they decimal or bit fields? 
> 
> -ENOPARSE. A number is a number. Its representation in C code may be
> decimal or hexadecimal (or...). And sure, 0 and 0x0 are different
> spellings of the same thing. The data sheet lists the possible values in
> terms of individual bits, so I suppose I could even do 0b0000 and
> 0b0001, but that's too unusual (even if perfectly acceptable by gcc).

What does datasheet define? bits or the value in a 4-bit field?
If bits, why don't you put it that way

#define ISL12022_INT_FO_OFF	0
#define ISL12022_INT_FO_32K	BIT(0)

?

It's a nit-pick, of course, but the nuance is that proposed form might give a
hint to the reader, current -- not.

> > To me seems like the 0x can be dropped.
> 
> Can, but won't, a single hex digit is more natural way to represent a
> four-bit field.

-- 
With Best Regards,
Andy Shevchenko





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux