Re: [PATCH v3] pinctrl: baytrail: Clear direct_irq_en flag on broken configs

[Hans de Goede <hdegoede@xxxxxxxxxx>]

Hi,

On 1/12/22 21:44, Andy Shevchenko wrote:
> On Wed, Jan 12, 2022 at 08:58:00PM +0100, Hans de Goede wrote:
>> On 1/8/22 19:54, kernel test robot wrote:
> 
>>>>> drivers/pinctrl/intel/pinctrl-baytrail.c:1483:58: warning: format specifies type 'long' but the argument has type 'int' [-Wformat]
>>>                    dev_dbg(vg->dev, "Pin %i: uses direct IRQ %ld\n", pin, match - direct_irq);
>>>                                                              ~~~          ^~~~~~~~~~~~~~~~~~
>>>                                                              %d
>>>    include/linux/dev_printk.h:163:47: note: expanded from macro 'dev_dbg'
>>>                    dev_printk(KERN_DEBUG, dev, dev_fmt(fmt), ##__VA_ARGS__); \
>>>                                                        ~~~     ^~~~~~~~~~~
>>>    include/linux/dev_printk.h:129:34: note: expanded from macro 'dev_printk'
>>>                    _dev_printk(level, dev, fmt, ##__VA_ARGS__);            \
>>>                                            ~~~    ^~~~~~~~~~~
>>>    1 warning generated.
>>
>> Hmm, ok. so x86_64 needs a %ld for the pointer arithmic result on i386 needs a %d
>> without the 'l' what fun. I'll just store it in a temp int variable in the next
>> version.
> 
> Why not to use uintptr_t and corresponding specifier (or ptrdiff_t)?

those or long resp. int depending on the arch to, but I could just
cast the result of the "match - direct_irq" pointer arithmetic to
an int, however due to the other changes in v4 using a local variable
seems cleaner, see the v4 which I'm about to send out in a couple of
minutes.

I think you will find v4 interesting because I've done a detailed
analysis of how the pinctrl conf0 pad register trigger bits and the IO-APIC
trigger bits work together, which is quite enlightening to how this all
works (and AFAICT not documented).

Regards,

Hans