On Fri, Oct 21, 2022 at 05:04:37AM +0530, Deepak R Varma wrote: > On Fri, Oct 21, 2022 at 07:56:05AM +0200, Greg KH wrote: > > On Fri, Oct 21, 2022 at 11:21:06AM +0530, Praveen Kumar wrote: > > > On 21-10-2022 03:02, Deepak R Varma wrote: > > > > Simple variants of macros PlatformEFIOWrite and PlatformEFIORead are > > > > defined but never used. As they do not appear to be designed for anything > > > > significant, we can remove them to avoid unexpected usage. > > > > > > > > Suggested-by: Julia Lawall <julia.lawall@xxxxxxxx> > > > > Signed-off-by: Deepak R Varma <drv@xxxxxxxxx> > > > > --- > > > > > > > > Changes in v4: > > > > 1. Patch newly added to the patch set. > > > > > > > > > > > > drivers/staging/r8188eu/include/rtw_io.h | 14 -------------- > > > > 1 file changed, 14 deletions(-) > > > > > > > > diff --git a/drivers/staging/r8188eu/include/rtw_io.h b/drivers/staging/r8188eu/include/rtw_io.h > > > > index 87fcf6c94ff3..e9744694204b 100644 > > > > --- a/drivers/staging/r8188eu/include/rtw_io.h > > > > +++ b/drivers/staging/r8188eu/include/rtw_io.h > > > > @@ -285,18 +285,4 @@ void bus_sync_io(struct io_queue *pio_q); > > > > u32 _ioreq2rwmem(struct io_queue *pio_q); > > > > void dev_power_down(struct adapter *Adapter, u8 bpwrup); > > > > > > > > -#define PlatformEFIOWrite1Byte(_a, _b, _c) \ > > > > - rtw_write8(_a, _b, _c) > > > > -#define PlatformEFIOWrite2Byte(_a, _b, _c) \ > > > > - rtw_write16(_a, _b, _c) > > > > -#define PlatformEFIOWrite4Byte(_a, _b, _c) \ > > > > - rtw_write32(_a, _b, _c) > > > > - > > > > -#define PlatformEFIORead1Byte(_a, _b) \ > > > > > > Can the naming be reworked to make more Linux friendly ? something like PLATFORM_EFIO_READ1BYTE or better if there are other suggestions? > > > Rest others as applicable ? > > > > All of these should just be removed entirely and the normal calls here > > made instead. There is no need for these #defines at all. > > Hello Greg, > The current patch scope results in removal of these #defines. Can you please > clarify what you mean by "normal calls here made instead"? Do you mean the > calling function should directly call the wrapped functions OR you are > suggesting converting these #defines to inline functions? The calling function should call the wrapped function instead, there is no need for another pointless level of indirection here. thanks, greg k-h
