Linux wireless drivers development
 help / color / mirror / Atom feed
From: Arend Van Spriel <arend.vanspriel@broadcom.com>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "Kalle Valo" <kvalo@codeaurora.org>,
	"Franky Lin" <franky.lin@broadcom.com>,
	"Hante Meuleman" <hante.meuleman@broadcom.com>,
	"Pieter-Paul Giesberts" <pieter-paul.giesberts@broadcom.com>,
	"Franky Lin" <frankyl@broadcom.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER"
	<brcm80211-dev-list.pdl@broadcom.com>,
	"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH V3 4/9] brcmfmac: add struct brcmf_pub parameter to the __brcmf_err
Date: Tue, 21 Mar 2017 14:49:10 +0100	[thread overview]
Message-ID: <76a76500-c673-78b6-a3f3-3cba68d21da8@broadcom.com> (raw)
In-Reply-To: <CACna6rzxbgkuvHWEk=7CgCzSeDfyR-RT_gHY=rwoZW_yC=LdOQ@mail.gmail.com>

On 23-2-2017 22:41, Rafał Miłecki wrote:
> Hey Arend,
> 
> On 8 February 2017 at 10:54, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 2-2-2017 22:33, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>
>>> This will allow getting struct device reference from the passed
>>> brcmf_pub for the needs of dev_err. More detailed messages are really
>>> important for home routers which frequently have 2 (or even 3) wireless
>>> cards supported by brcmfmac.
>>>
>>> Note that all calls are yet to be updated as for now brcmf_err macro
>>> always passes NULL. This will be handled in following patch to make this
>>> change easier to review.
>>
>> I prefer brcmf_err() to have struct device reference directly instead of
>> using brcmf_pub. That would remove the need for patches 5 till 7 as bus
>> specific code already has struct device. So I have acked the first three
>> patches, but would like to revise 8 and 9.
> 
> I wanted to have some better perspective so I analyzed few upstream
> Linux wireless drivers. It seems to be a pretty common pattern to have
> one struct describing hardware that gets passed across the whole
> driver. This way you can access any important info from any place of
> the driver & some will probably say it also simplifies a driver.
> 
> For example following drivers use following struct in almost every
> part of their code (across multiple files):
> ath9k: struct ath_hw
> ath10k: struct ath10k
> iwlmvm: struct iwl_mvm
> mt7601u: struct mt7601u_dev
> mwifiex: struct mwifiex_private
> rt2x00: struct rt2x00_dev
> 
> The most common / generic struct I found in brcmfmac was struct
> brcmf_pub. That's why I tried to use it for the commonly used
> brcmf_err.
> 
> What's the reason for hiding this struct from few random parts of the
> code? Is there any real gain from this?

Hi Rafał,

Time flies when you are ... well, me apparently. I realized I did not
get back on this and looked at it myself. In brcmfmac we have layering
with a common layer and bus specific layer. The interface between those
layers is in bus.h, ie. struct brcmf_bus which holds reference to struct
device. So I would think using struct brcmf_bus in brcmf_err() would be
best fit. I also looked at doing some type introspection using
__builtin_types_compatible_p() which is built-in function available in
both GCC and Clang. Might be worth exploring.

Regards,
Arend

  reply	other threads:[~2017-03-21 13:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-02 21:33 [PATCH V3 1/9] brcmfmac: merge two brcmf_err macros into one Rafał Miłecki
2017-02-02 21:33 ` [PATCH V3 2/9] brcmfmac: switch to C function (__brcmf_err) for printing errors Rafał Miłecki
2017-02-08  9:15   ` Arend Van Spriel
2017-02-02 21:33 ` [PATCH V3 3/9] brcmfmac: merge two remaining brcmf_err macros Rafał Miłecki
2017-02-08  9:52   ` Arend Van Spriel
2017-02-02 21:33 ` [PATCH V3 4/9] brcmfmac: add struct brcmf_pub parameter to the __brcmf_err Rafał Miłecki
2017-02-08  9:54   ` Arend Van Spriel
2017-02-08 10:00     ` Rafał Miłecki
2017-02-08 14:52       ` Kalle Valo
2017-02-08 15:09         ` Rafał Miłecki
2017-02-23 21:08     ` Rafał Miłecki
2017-02-23 21:41     ` Rafał Miłecki
2017-03-21 13:49       ` Arend Van Spriel [this message]
2017-02-02 21:33 ` [PATCH V3 5/9] brcmfmac: pcie: store private pointer to struct brcmf_pub Rafał Miłecki
2017-02-05 19:49   ` Arend Van Spriel
2017-02-02 21:33 ` [PATCH V3 6/9] brcmfmac: usb: " Rafał Miłecki
2017-02-02 21:33 ` [PATCH V3 7/9] brcmfmac: sdio: " Rafał Miłecki
2017-02-02 21:33 ` [PATCH V3 8/9] brcmfmac: modify all brcmf_err calls adding " Rafał Miłecki
2017-02-02 21:33 ` [PATCH V3 9/9] brcmfmac: use dev_err to print errors Rafał Miłecki
2017-02-08  9:02 ` [PATCH V3 1/9] brcmfmac: merge two brcmf_err macros into one Arend Van Spriel
2017-02-08 15:24 ` [V3,1/9] " Kalle Valo

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=76a76500-c673-78b6-a3f3-3cba68d21da8@broadcom.com \
    --to=arend.vanspriel@broadcom.com \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=franky.lin@broadcom.com \
    --cc=frankyl@broadcom.com \
    --cc=hante.meuleman@broadcom.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pieter-paul.giesberts@broadcom.com \
    --cc=rafal@milecki.pl \
    --cc=zajec5@gmail.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