Re: [PATCH 12/12] staging: r8188eu: hal_data_sz is set but never used

[Pavel Skripkin <paskripkin@gmail.com>]

On 12/5/21 18:22, Michael Straube wrote:
>> Not related to your patch, but not returning an error from this function 
>>   looks very dangerous to me.
>> 
>> adapt->HalData is used in GET_HAL_DATA() macro all across the driver 
>> code and nobody checks if it valid or not. If allocation fails here, 
>> than we will likely hit GPF while accessing hal_data fields.
>> 
>> Maybe we can embed struct hal_data_8188e instead of storing a pointer to 
>> it?
> 
> Rethinking my prevoius answer, embedding struct hal_data_8188e is the
> better solution I think.
> 

I also think so. At least, it looks like this is very core structure and 
embedding it into struct adapter sounds more reasonable.

Also, it is one step further to make struct adapter more consistent. For 
now it looks confusing: some of privs are pointers and others are not:

struct adapter {
...
	struct dvobj_priv *dvobj;
	struct	mlme_priv mlmepriv;
	struct	mlme_ext_priv mlmeextpriv;
	struct	cmd_priv	cmdpriv;
	struct	evt_priv	evtpriv;
	struct	io_priv	iopriv;
	struct	xmit_priv	xmitpriv;
	struct	recv_priv	recvpriv;
	struct	sta_priv	stapriv;
	struct	security_priv	securitypriv;
	struct	registry_priv	registrypriv;
	struct	pwrctrl_priv	pwrctrlpriv;
	struct	eeprom_priv eeprompriv;
	struct	led_priv	ledpriv;
	struct	hostapd_priv	*phostapdpriv;
	struct wifidirect_info	wdinfo;

	void *HalData;

...

and even why Haldata is void *, but not struct hal_data_8188e * :)


so many questions and so few answers....



With regards,
Pavel Skripkin