Re: [PATCH 4.19.y-cip 08/39] soc: renesas: r8a7795-sysc: Fix power request conflicts
Geert Uytterhoeven <geert@...>
Hi Biju, Pavel,
On Thu, Dec 19, 2019 at 8:43 AM Biju Das <biju.das@...> wrote:
struct soc_device_attribute.data contains an opaque value, just like-----Original Message-----Dien, Geert,
e.g. of_device_id.data and platform_device_id.driver_data.
In some structs, the opaque value is a "void *", in other structs it is an
"unsigned long". But the actual meaning and contents depend on the
driver. It may be used to store a pointer to a struct with features,
an integer value, or a feature mask.
Conversion between pointer and integer is done by casting to "void *",
or to "uintptr_t" (historically, "unsigned long" was used for this, but
modern code uses "uintptr_t").
In this case, it contains a feature mask, which fits in "u32", which is
"unsigned int", and "(unsigned) int" is still the standard type for any random
variable that doesn't have special requirements.
- To store the feature mask, a cast to "void *" is needed.
- To retrieve the feature mask, a cast to "uintptr_t" is needed.
A cast to "u32" would cause a warning on 64-bit platforms, due to
the truncation of a 64-bit pointer to a 32-bit integer.
I agree "unsigned long" could have been a suitable type for "quirks"
as well, but I see no reason to make that change when backporting
a patch to stable.
$ git grep "unsigned long quirks" | wc -l
$ git grep "unsigned int quirks" | wc -l
$ git grep "u32 quirks" | wc -l
Hope this helps.
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds