On Sun, Mar 14, 2021 at 10:01 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > - byData = inb(0x61); \ > > + inb(0x61); \ > > Are you sure that the compiler does not make the inb() now go away? Hey, Greg! Take what you are about to read with a BIG grain of salt because I'm just learning about the details of what's going on and the tools at my disposal. On v5.11 with an allyesconfig, by changing the value of CB_DELAY_LOOP_WAIT in mac.h to 100 to force the compiler to include the `else` path that includes the for with the inb() call, comparing the resulting srom.o files before/after the patch: Compiling with only the value in mac.h changed: $ size drivers/staging/vt6655/srom.o text data bss dec hex filename 959 0 0 959 3bf drivers/staging/vt6655/srom.o By removing the variable in the macro: $ size drivers/staging/vt6655/srom.o text data bss dec hex filename 959 0 0 959 3bf drivers/staging/vt6655/srom.o By also removing the inb() call, in other words, keeping an empty for: $ size drivers/staging/vt6655/srom.o text data bss dec hex filename 865 0 0 865 361 drivers/staging/vt6655/srom. That being the case, I think that inb is not fading away by removing the variable... at least in my environment. Just in case, it's not like I _want_ the patch to be accepted. I took it as an exercise and if you think that you want to play safe and reject it, it's fine. It was still valuable to me because of your question about the function going away and me trying to find out. Thanks!
