linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Arend van Spriel" <arend@broadcom.com>
To: "Hauke Mehrtens" <hauke@hauke-m.de>
Cc: linville@tuxdriver.com, brudley@broadcom.com,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH 16/18] brcmsmac: do not call brcms_c_chipmatch() for non PCI
Date: Thu, 7 Jun 2012 21:06:29 +0200	[thread overview]
Message-ID: <4FD0FBB5.6040008@broadcom.com> (raw)
In-Reply-To: <4FD0AA77.4000108@hauke-m.de>

On 06/07/2012 03:19 PM, Hauke Mehrtens wrote:
> Hi Arend,
> 
> On 06/06/2012 01:23 PM, Arend van Spriel wrote:
>> On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
>>> brcms_c_chipmatch() just works for PCIe devices and returns false for
>>> non PCIe devices. This stops brcms_ops_stop() from calling it when the
>>> devices is not a PCIe device.
>>
>> Although this is true you may want to consider what this function
>> provides. The intent is to have a more accurate filter to determine
>> support the device by the driver, ie. more accurate than what is in the
>> driver device table.
>>
>> So in brcms_c_chipmatch() we may want a host-type independent filtering
>> and validate bcma_device_id, bcma_chipinfo, and possibly bcma_boardinfo.
> I do not like this function at all. ;-)
> 
> Are these restrictions in this function really needed? I would more like
> to restrict it to something like core revs, which is done in the device
> table and the phy types and versions. A restriction by chipid would also
> be reasonable as some chips are needing some special workarounds, these
> checks could also be done for SoCs.

I look where the function came from and it is called in several places
in our proprietary driver, which has a pretty coarse filter in the
device table.

The BCMA device table in brcmsmac is more finegrained and currently has
entries for the different 80211 core revisions. However, the brcmsmac
may have additional revision requirement for chipcommon and other cores
inside the chip so this function may have it merits for checking that.

Gr. AvS


  reply	other threads:[~2012-06-07 19:06 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-05 23:07 [PATCH 00/18] brcmsmac: update to get SoCs working Hauke Mehrtens
2012-06-05 23:07 ` [PATCH 01/18] brcmsmac: remove PCIE() makro Hauke Mehrtens
2012-06-07 20:05   ` Arend van Spriel
2012-06-10 13:28     ` Hauke Mehrtens
2012-06-11  7:51       ` Arend van Spriel
2012-06-11 21:36         ` Hauke Mehrtens
2012-06-05 23:07 ` [PATCH 02/18] brcmsmac: remove PCI_FORCEHT() makro Hauke Mehrtens
2012-06-07 20:12   ` Arend van Spriel
2012-06-05 23:07 ` [PATCH 03/18] brcmsmac: remove ai_get_buscore{type,rev}() Hauke Mehrtens
2012-06-06  9:17   ` Arend van Spriel
2012-06-07 13:48     ` Hauke Mehrtens
2012-06-07 19:36       ` Arend van Spriel
2012-06-05 23:07 ` [PATCH 04/18] brcmsmac: use container_of instead of cast Hauke Mehrtens
2012-06-06  9:27   ` Arend van Spriel
2012-06-07 13:45     ` Hauke Mehrtens
2012-06-05 23:07 ` [PATCH 05/18] brcmsmac: remove ai_findcore() Hauke Mehrtens
2012-06-06  9:28   ` Arend van Spriel
2012-06-05 23:07 ` [PATCH 06/18] brcmsmac: remove si_pmu_init() and si_pmu_res_init() Hauke Mehrtens
2012-06-06  9:31   ` Arend van Spriel
2012-06-05 23:07 ` [PATCH 07/18] brcmsmac: remove si_pmu_spuravoid_pllupdate() Hauke Mehrtens
2012-06-06  9:33   ` Arend van Spriel
2012-06-05 23:07 ` [PATCH 08/18] brcmsmac: remove some redundant chip common workarounds Hauke Mehrtens
2012-06-06 12:14   ` Arend van Spriel
2012-06-07 12:59     ` Hauke Mehrtens
2012-06-05 23:07 ` [PATCH 09/18] brcmsmac: use core id constants from bcma Hauke Mehrtens
2012-06-06  9:43   ` Arend van Spriel
2012-06-05 23:07 ` [PATCH 10/18] brcmsmac: use chip and package " Hauke Mehrtens
2012-06-06  9:44   ` Arend van Spriel
2012-06-05 23:07 ` [PATCH 11/18] brcmsmac: remove some unnessessacry casts and void pointer Hauke Mehrtens
2012-06-06  9:46   ` Arend van Spriel
2012-06-05 23:07 ` [PATCH 12/18] brcmsmac: add a conditions for core rev 17 again Hauke Mehrtens
2012-06-05 23:07 ` [PATCH 13/18] brcmsmac: add some workarounds for other chips again Hauke Mehrtens
2012-06-06 10:03   ` Arend van Spriel
2012-06-07 13:45     ` Hauke Mehrtens
2012-06-07 19:34       ` Arend van Spriel
2012-06-08 11:31         ` Jonas Gorski
2012-06-08 16:54           ` Arend van Spriel
2012-06-08 17:49             ` Jonas Gorski
2012-06-05 23:07 ` [PATCH 14/18] brcmsmac: extend xmtfifo_sz array Hauke Mehrtens
2012-06-06 10:24   ` Arend van Spriel
2012-06-07 13:33     ` Hauke Mehrtens
2012-06-07 19:21       ` Arend van Spriel
2012-06-10 13:10         ` Hauke Mehrtens
2012-06-11  7:59           ` Arend van Spriel
2012-06-11 21:44             ` Hauke Mehrtens
2012-06-05 23:07 ` [PATCH 15/18] brcmsmac: fix DMA on SoCs Hauke Mehrtens
2012-06-06 11:10   ` Arend van Spriel
2012-06-07 13:29     ` Hauke Mehrtens
2012-06-05 23:07 ` [PATCH 16/18] brcmsmac: do not call brcms_c_chipmatch() for non PCI Hauke Mehrtens
2012-06-06 11:23   ` Arend van Spriel
2012-06-07 13:19     ` Hauke Mehrtens
2012-06-07 19:06       ` Arend van Spriel [this message]
2012-06-10 13:03         ` Hauke Mehrtens
2012-06-05 23:07 ` [PATCH 17/18] brcmsmac: fix read in write_phy_reg Hauke Mehrtens
2012-06-06 11:39   ` Arend van Spriel
2012-06-05 23:07 ` [PATCH 18/18] brcmsmac: handle non PCI devices in the phy code Hauke Mehrtens
2012-06-06 11:43   ` Arend van Spriel
2012-06-07 13:00     ` Hauke Mehrtens

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=4FD0FBB5.6040008@broadcom.com \
    --to=arend@broadcom.com \
    --cc=brudley@broadcom.com \
    --cc=hauke@hauke-m.de \
    --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).