linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hauke Mehrtens <hauke@hauke-m.de>
To: Dominique Martinet <asmadeus@codewreck.org>
Cc: Julian Calaby <julian.calaby@gmail.com>,
	linville@tuxdriver.com, arend@broadcom.com,
	brcm80211-dev-list@broadcom.com, linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2 11/18] brcmsmac: remove some unnessessacry casts and void pointer
Date: Mon, 02 Jul 2012 19:44:57 +0200	[thread overview]
Message-ID: <4FF1DE19.4070304@hauke-m.de> (raw)
In-Reply-To: <20120702075450.GB18990@nautica>

On 07/02/2012 09:54 AM, Dominique Martinet wrote:
> Julian Calaby wrote on Mon, Jul 02, 2012 :
>> On Sat, Jun 30, 2012 at 11:16 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
>>> index 478b374..8bad8b6 100644
>>> --- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
>>> +++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
>>> @@ -4241,10 +4240,8 @@ static void brcms_b_watchdog(void *arg)
>>>  }
>>>
>>>  /* common watchdog code */
>>> -static void brcms_c_watchdog(void *arg)
>>> +static void brcms_c_watchdog(struct brcms_c_info *wlc)
>>>  {
>>> -       struct brcms_c_info *wlc = (struct brcms_c_info *) arg;
>>> -
>>>         BCMMSG(wlc->wiphy, "wl%d\n", wlc->pub->unit);
>>>
>>>         if (!wlc->pub->up)
>>> @@ -4284,7 +4281,9 @@ static void brcms_c_watchdog(void *arg)
>>>
>>>  static void brcms_c_watchdog_by_timer(void *arg)
>>>  {
>>> -       brcms_c_watchdog(arg);
>>> +       struct brcms_c_info *wlc = (struct brcms_c_info *) arg;
>>> +
>>> +       brcms_c_watchdog(wlc);
>>
>> You remove 2 cases of this pattern in your patch then add one. Why?
> 
> I'm not Hauke :) but as far as I understand, brcms_c_watchdog_by_timer
> is used by brcms_init_timer which expects a void (*fn) (void *); and
> which is also used with brcms_c_radio_timer
> Admitedly, brcms_c_radio_timer also uses a struct brcms_c_info* as
> argument, so everything could be change this way, but I think it's not
> completely insane to keep callbacks as void* :)
> 
> I also see the point of removing this "pattern" since it makes it easier
> to understand with the proper type information.
> 
> Regards,
> 
Yes Dominique is right, that's the reason. I wanted to eliminate some of
the void *args. I left the void *args when it was called by a callback
function.

Hauke

  reply	other threads:[~2012-07-02 17:45 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-30 13:16 [PATCH v2 00/18] brcmsmac: update to get SoCs working Hauke Mehrtens
2012-06-30 13:16 ` [PATCH v2 01/18] brcmsmac: remove PCIE() macro Hauke Mehrtens
2012-07-03  7:07   ` Arend van Spriel
2012-06-30 13:16 ` [PATCH v2 02/18] brcmsmac: remove PCI_FORCEHT() macro Hauke Mehrtens
2012-06-30 13:16 ` [PATCH v2 03/18] brcmsmac: remove ai_get_buscore{type,rev}() Hauke Mehrtens
2012-06-30 13:16 ` [PATCH v2 04/18] brcmsmac: use container_of instead of cast Hauke Mehrtens
2012-06-30 13:16 ` [PATCH v2 05/18] brcmsmac: remove ai_findcore() Hauke Mehrtens
2012-06-30 13:16 ` [PATCH v2 06/18] brcmsmac: remove si_pmu_init() and si_pmu_res_init() Hauke Mehrtens
2012-06-30 13:16 ` [PATCH v2 07/18] brcmsmac: remove si_pmu_spuravoid_pllupdate() Hauke Mehrtens
2012-06-30 13:16 ` [PATCH v2 08/18] brcmsmac: remove some redundant chip common workarounds Hauke Mehrtens
2012-06-30 13:16 ` [PATCH v2 09/18] brcmsmac: use core id constants from bcma Hauke Mehrtens
2012-06-30 13:16 ` [PATCH v2 10/18] brcmsmac: use chip and package " Hauke Mehrtens
2012-06-30 13:16 ` [PATCH v2 11/18] brcmsmac: remove some unnessessacry casts and void pointer Hauke Mehrtens
2012-07-01 23:59   ` Julian Calaby
2012-07-02  7:54     ` Dominique Martinet
2012-07-02 17:44       ` Hauke Mehrtens [this message]
2012-07-02 23:01         ` Julian Calaby
2012-06-30 13:16 ` [PATCH v2 12/18] brcmsmac: add a conditions for core rev 17 again Hauke Mehrtens
2012-07-03  7:06   ` Arend van Spriel
2012-06-30 13:16 ` [PATCH v2 13/18] brcmsmac: add some workarounds for other chips again Hauke Mehrtens
2012-07-03  7:08   ` Arend van Spriel
2012-06-30 13:16 ` [PATCH v2 14/18] brcmsmac: extend xmtfifo_sz array Hauke Mehrtens
2012-07-02  0:01   ` Julian Calaby
2012-07-02 18:15     ` [PATCH v3 " Hauke Mehrtens
2012-07-03  7:08   ` [PATCH v2 " Arend van Spriel
2012-06-30 13:16 ` [PATCH v2 15/18] brcmsmac: fix DMA on SoCs Hauke Mehrtens
2012-07-03  7:10   ` Arend van Spriel
2012-06-30 13:16 ` [PATCH v2 16/18] brcmsmac: extend brcms_c_chipmatch() to also handle non PCIe devices Hauke Mehrtens
2012-07-03  7:11   ` Arend van Spriel
2012-06-30 13:16 ` [PATCH v2 17/18] brcmsmac: fix read in write_phy_reg Hauke Mehrtens
2012-06-30 13:16 ` [PATCH v2 18/18] brcmsmac: handle non PCI devices in the phy code Hauke Mehrtens
2012-07-03  7:11   ` Arend van Spriel
2012-07-02  0:04 ` [PATCH v2 00/18] brcmsmac: update to get SoCs working Julian Calaby
2012-07-03  7:13 ` Arend van Spriel
2012-07-06 18:35   ` John W. Linville
2012-07-08 19:10     ` Arend van Spriel

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=4FF1DE19.4070304@hauke-m.de \
    --to=hauke@hauke-m.de \
    --cc=arend@broadcom.com \
    --cc=asmadeus@codewreck.org \
    --cc=brcm80211-dev-list@broadcom.com \
    --cc=julian.calaby@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).