linux-kernel - Re: [PATCH 15/20] staging/wilc1000: pass hif operations through initialization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Nov 2015 12:39:41 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	glen lee <glen.lee@...el.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Johnny Kim <johnny.kim@...el.com>,
	Austin Shin <austin.shin@...el.com>,
	Chris Park <chris.park@...el.com>,
	Tony Cho <tony.cho@...el.com>, Leo Kim <leo.kim@...el.com>,
	linux-wireless@...r.kernel.org, devel@...verdev.osuosl.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 15/20] staging/wilc1000: pass hif operations through initialization

On Thursday 12 November 2015 19:05:41 glen lee wrote:
> Hi arnd,
> 
> I appreciate the patches.
> I did test this patch series on h/w which is arm based MCU.
>  From this patch wilc is not working properly. After downloading firmware, the firmware cannot start and it fails.
> I double check this patch and the previous one(14/20) which works fine.
> I cannot find the problem in this patch at the moment. I will see if I can find something,
> and I'd appreciate if you would help with it.
> 

I've looked at it some more, but didn't find anything obvious, here are some
possible things I found:


> > -struct wilc_hif_func wilc_hif_sdio = {
> > -	sdio_init,
> > -	sdio_deinit,
> > -	sdio_read_reg,
> > -	sdio_write_reg,
> > -	sdio_read,
> > -	sdio_write,
> > -	sdio_sync,
> > -	sdio_clear_int,
> > -	sdio_read_int,
> > -	sdio_clear_int_ext,
> > -	sdio_read_size,
> > -	sdio_write,
> > -	sdio_read,
> > -	sdio_sync_ext,
> > -
> > -	sdio_set_max_speed,
> > -	sdio_set_default_speed,
> > +const struct wilc_hif_func wilc_hif_sdio = {
> > +	.hif_init = sdio_init,
> > +	.hif_deinit = sdio_deinit,
> > +	.hif_read_reg = sdio_read_reg,
> > +	.hif_write_reg = sdio_write_reg,
> > +	.hif_block_rx = sdio_read,
> > +	.hif_block_tx = sdio_write,
> > +	.hif_sync = sdio_sync,
> > +	.hif_clear_int = sdio_clear_int,
> > +	.hif_read_int = sdio_read_int,
> > +	.hif_clear_int_ext = sdio_clear_int_ext,
> > +	.hif_read_size = sdio_read_size,
> > +	.hif_block_rx_ext = sdio_write,
> > +	.hif_block_tx_ext = sdio_read,
> > +	.hif_sync_ext = sdio_sync_ext,
> > +	.hif_set_max_bus_speed = sdio_set_max_speed,
> > +	.hif_set_default_bus_speed = sdio_set_default_speed,
> >   };

If the callbacks are not in the same order here, something could
in theory go wrong. I've tried to verify them by inspection and
could not find anything here, but you can try reverting this part.

> >   	memset((void *)&g_wlan, 0, sizeof(wilc_wlan_dev_t));
> >   	g_wlan.io_type = wilc->io_type;
> > -
> > -#ifdef WILC_SDIO
> > -	if (!wilc_hif_sdio.hif_init(wilc, wilc_debug)) {
> > -		ret = -EIO;
> > -		goto _fail_;
> > -	}
> > -	memcpy((void *)&g_wlan.hif_func, &wilc_hif_sdio,
> > -	       sizeof(struct wilc_hif_func));
> > -#else
> > -	if (!wilc_hif_spi.hif_init(wilc, wilc_debug)) {
> > +	g_wlan.hif_func = *wilc->ops;
> > +	if (!g_wlan.hif_func.hif_init(wilc, wilc_debug)) {
> >   		ret = -EIO;
> >   		goto _fail_;
> >   	}
> > -	memcpy((void *)&g_wlan.hif_func, &wilc_hif_spi,
> > -	       sizeof(struct wilc_hif_func));
> > -#endif

This is the most likely part I found:

doing an assigment instead of memcpy should not make a difference,
but my new version also called init after copying over the
operations rather than before. This seemed to be the correct
order when I did it, but it is a change in behavior that might
cause problems if some code relies on the hif_func structure
to be empty at the time that hif_init is called.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/