All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Arend van Spriel <arend@broadcom.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
	Hante Meuleman <meuleman@broadcom.com>
Subject: Re: [PATCH 18/21] brcmfmac: switch to new platform data
Date: Fri, 04 Mar 2016 16:49:32 +0200	[thread overview]
Message-ID: <87a8mexpqb.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <1455704830-10088-19-git-send-email-arend@broadcom.com> (Arend van Spriel's message of "Wed, 17 Feb 2016 11:27:07 +0100")

Arend van Spriel <arend@broadcom.com> writes:

> From: Hante Meuleman <meuleman@broadcom.com>
>
> Platform data is only available for sdio. With this patch a new
> platform data structure is being used which allows for platform
> data for any device and configurable per device. This patch only
> switches to the new structure and adds support for SDIO devices.
>
> Reviewed-by: Arend Van Spriel <arend@broadcom.com>
> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
> Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
> Signed-off-by: Arend van Spriel <arend@broadcom.com>

It's more work to review patches which rename a file and adds new
features at the same time. Splitting this to two patches, first a simple
rename and then adding support for SDIO, would have been much nicer.

>  static void brcmf_mp_attach(void)
>  {
> +	/* If module param firmware path is set then this will always be used,
> +	 * if not set then if available use the platform data version. To make
> +	 * sure it gets initialized at all, always copy the module param version
> +	 */
>  	strlcpy(brcmf_mp_global.firmware_path, brcmf_firmware_path,
>  		BRCMF_FW_ALTPATH_LEN);
> +	if ((brcmfmac_pdata) && (brcmfmac_pdata->fw_alternative_path) &&
> +	    (brcmf_mp_global.firmware_path[0] == '\0')) {
> +		strlcpy(brcmf_mp_global.firmware_path,
> +			brcmfmac_pdata->fw_alternative_path,
> +			BRCMF_FW_ALTPATH_LEN);
> +	}

[...]

> +/**
> + * struct brcmfmac_platform_data - BRCMFMAC specific platform data.
> + *
> + * @power_on:	This function is called by the brcmfmac driver when the module
> + *		gets loaded. This can be particularly useful for low power
> + *		devices. The platform spcific routine may for example decide to
> + *		power up the complete device. If there is no use-case for this
> + *		function then provide NULL.
> + * @power_off:	This function is called by the brcmfmac when the module gets
> + *		unloaded. At this point the devices can be powered down or
> + *		otherwise be reset. So if an actual power_off is not supported
> + *		but reset is supported by the devices then reset the devices
> + *		when this function gets called. This can be particularly useful
> + *		for low power devices. If there is no use-case for this
> + *		function then provide NULL.
> + */
> +struct brcmfmac_platform_data {
> +	void	(*power_on)(void);
> +	void	(*power_off)(void);
> +	char	*fw_alternative_path;
> +	int	device_count;
> +	struct brcmfmac_pd_device devices[0];
> +};

If I understood correctly this undocumented, and not mentioned in the
commit log, fw_alternative_path is a new feature in platform data. I
guess it provides a different firmware image name for the device so that
devices can have different firmware images on the same system?

It's not pretty but I guess okayish. Opinions?

-- 
Kalle Valo

  reply	other threads:[~2016-03-04 14:49 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-17 10:26 [PATCH 00/21] brcmfmac: driver setting concept and other changes Arend van Spriel
2016-02-17 10:26 ` [PATCH 01/21] brcmfmac: change function name for brcmf_cfg80211_wait_vif_event_timeout() Arend van Spriel
2016-03-07 12:19   ` [01/21] brcmfmac: change function name forbrcmf_cfg80211_wait_vif_event_timeout() Kalle Valo
2016-03-07 12:49     ` Kalle Valo
2016-03-07 20:03       ` Arend Van Spriel
2016-03-08  8:46         ` Kalle Valo
2016-02-17 10:26 ` [PATCH 02/21] brcmfmac: Limit memory allocs to <64K Arend van Spriel
2016-02-17 10:26 ` [PATCH 03/21] brcmfmac: check for wowl support before enumerating feature flag Arend van Spriel
2016-02-17 10:26 ` [PATCH 04/21] brcmfmac: Configure country code using device specific settings Arend van Spriel
2016-02-17 10:26 ` [PATCH 05/21] brcmfmac: Add length checks on firmware events Arend van Spriel
2016-02-17 10:26 ` [PATCH 06/21] brcmfmac: add neighbor discovery offload ip address table configuration Arend van Spriel
2016-02-17 10:26 ` [PATCH 07/21] brcmfmac: check return for ARP ip setting iovar Arend van Spriel
2016-02-17 10:26 ` [PATCH 08/21] brcmfmac: use device memsize config from fw if defined Arend van Spriel
2016-02-17 10:26 ` [PATCH 09/21] brcmfmac: use bar1 window size as provided by pci subsystem Arend van Spriel
2016-02-17 10:26 ` [PATCH 10/21] brcmfmac: add support for the PCIE 4366c0 chip Arend van Spriel
2016-02-17 10:27 ` [PATCH 11/21] brcmfmac: remove pcie gen1 support Arend van Spriel
2016-02-17 10:27 ` [PATCH 12/21] brcmfmac: increase timeout for tx eapol Arend van Spriel
2016-02-17 10:27 ` [PATCH 13/21] brcmfmac: move module init and exit to common Arend van Spriel
2016-02-17 10:27 ` [PATCH 14/21] brcmfmac: add wowl gtk rekeying offload support Arend van Spriel
2016-02-17 10:27 ` [PATCH 15/21] brcmfmac: move platform data retrieval code to common Arend van Spriel
2016-02-17 10:27 ` [PATCH 16/21] brcmfmac: keep ARP and ND offload enabled during WOWL Arend van Spriel
2016-02-17 10:27 ` [PATCH 17/21] brcmfmac: fix sdio sg table alloc crash Arend van Spriel
2016-02-17 10:27 ` [PATCH 18/21] brcmfmac: switch to new platform data Arend van Spriel
2016-03-04 14:49   ` Kalle Valo [this message]
2016-03-04 20:02     ` Arend Van Spriel
2016-02-17 10:27 ` [PATCH 19/21] brcmfmac: merge platform data and module paramaters Arend van Spriel
2016-02-17 10:27 ` [PATCH 20/21] brcmfmac: integrate add_keyext in add_key Arend van Spriel
2016-02-17 10:27 ` [PATCH 21/21] brcmfmac: add 802.11w management frame protection support Arend van Spriel
2016-02-25 22:26 ` [PATCH 00/21] brcmfmac: driver setting concept and other changes Rafał Miłecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a8mexpqb.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@codeaurora.org \
    --cc=arend@broadcom.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=meuleman@broadcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.