Hi Marek, On 7 June 2017 at 06:41, Marek Vasut <ma...@denx.de> wrote: > On 06/07/2017 02:38 PM, Simon Glass wrote: >> +Tom for comment >> >> Hi Marek, >> >> On 7 June 2017 at 00:27, Marek Vasut <ma...@denx.de> wrote: >>> On 06/07/2017 02:16 AM, Simon Glass wrote: >>>> Hi, >>>> >>>> On 6 June 2017 at 17:59, Dr. Philipp Tomsich >>>> <philipp.toms...@theobroma-systems.com> wrote: >>>>> Simon, >>>>> >>>>>> On 06 Jun 2017, at 23:09, Simon Glass <s...@chromium.org> wrote: >>>>>> >>>>>> Hi Philipp, >>>>>> >>>>>> On 6 June 2017 at 07:42, Philipp Tomsich >>>>>> <philipp.toms...@theobroma-systems.com> wrote: >>>>>>> The regs_otg field in uintptr_t of the platform data structure for >>>>>>> dwc2-otg has thus far been an unsigned int, but will eventually be >>>>>>> casted into a void*. >>>>>>> >>>>>>> This raises the following error with GCC 6.3 and buildman: >>>>>>> ../drivers/usb/gadget/dwc2_udc_otg.c: In function 'dwc2_udc_probe': >>>>>>> ../drivers/usb/gadget/dwc2_udc_otg.c:821:8: warning: cast to pointer >>>>>>> from integer of different size [-Wint-to-pointer-cast] >>>>>>> reg = (struct dwc2_usbotg_reg *)pdata->regs_otg; >>>>>>> ^ >>>>>>> >>>>>>> This changes regs_otg to a uintptr_t to ensure that it is large enough >>>>>>> to hold any valid pointer (and fix the associated warning). >>>>>>> >>>>>>> Signed-off-by: Philipp Tomsich <philipp.toms...@theobroma-systems.com> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Changes in v2: >>>>>>> - (new patch) fix a int-to-pointer cast warning for regs_otg in >>>>>>> dwc2-otg to fix a buildman failure for u-boot-rockchip/master@2b19b2f >>>>>>> >>>>>>> include/usb/dwc2_udc.h | 2 +- >>>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/include/usb/dwc2_udc.h b/include/usb/dwc2_udc.h >>>>>>> index 7324d8a..1a370e0 100644 >>>>>>> --- a/include/usb/dwc2_udc.h >>>>>>> +++ b/include/usb/dwc2_udc.h >>>>>>> @@ -16,7 +16,7 @@ struct dwc2_plat_otg_data { >>>>>>> int phy_of_node; >>>>>>> int (*phy_control)(int on); >>>>>>> unsigned int regs_phy; >>>>>>> - unsigned int regs_otg; >>>>>>> + uintptr_t regs_otg; >>>>>> >>>>>> Can you use ulong instead? >>>>> >>>>> Sure, but can I first ask “why?”. >>>>> I may reopen an old discussion with this… if so, forgive my ignorance: >>>>> >>>>> uintptr_t makes the most sense for this use case in the C99 (or later) >>>>> type system, >>>>> as we want this field to hold an integer (i.e. the address from the >>>>> physical memory >>>>> map for one of the register blocks) that will be casted into a pointer. >>>>> The uintptr_t type will always the matching size in any and all >>>>> programming models; >>>>> in contrast, ulong would be wrong for LLP64 (and LLP64 probably “doesn’t >>>>> matter” >>>>> in the context of U-Boot anyway). >>>>> >>>>> What I always found odd, was that uintptr_t is optional according to >>>>> ISO9899. >>>>> I would thus not have been surprised if there’s a concern for portability >>>>> between >>>>> compilers behind this, but then again … U-Boot makes extensive use of GCC >>>>> extensions (such as inline assembly). >>>>> >>>>> So I am apparently missing something here. >>>> >>>> I don't know of any deep reason except that long is defined to be able >>>> to hold an address, and ulong makes sense since an address is >>>> generally considered unsigned. >>>> >>>> U-Boot by convention uses ulong for addresses. >>> >>> I was under the impression that u-boot by convention uses uintptr_t for >>> addresses. >>> >>>> You can see this all >>>> around the code base so I am really just arguing in favour of >>>> consistency (and I suppose ulong is easier to type!) >>> >>> Then I guess half of the codebase is inconsistent. >> >> Actually about 10%: >> >> git grep uintptr_t |wc -l >> 395 >> git grep ulong |wc -l >> 4024 > > I don't think this is a valid way to count it at all, since uintptr_t is > only used for casting pointer to number, while ulong is used for > arbitrary numbers. > >> Clearly we use ulong all over the place for addresses - see image.c, >> most commands, etc. > > But none of those use ulong as device address pointers .
Is there a distinction between a device address pointer and some other type of address? > >> If we are going to change then it should be a >> deliberate decision and a tree-wide update. I'm happy enough with >> ulong. >> >> Tom, what do you what to do here? >> Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot