On Fri, 15 Feb 2019 at 10:40, Arend Van Spriel
<arend.vanspriel@xxxxxxxxxxxx> wrote:
> On 2/15/2019 9:37 AM, Rafał Miłecki wrote:
> > On Fri, 15 Feb 2019 at 07:43, Rafał Miłecki <zajec5@xxxxxxxxx> wrote:
> >> From: Rafał Miłecki <rafal@xxxxxxxxxx>
> >>
> >> This recently added macro provides more meaningful error messages thanks
> >> to identifying a specific wiphy. It's especially important on systems
> >> with few cards supported by the same (brcmfmac) driver.
> >>
> >> Signed-off-by: Rafał Miłecki <rafal@xxxxxxxxxx>
> >> Acked-by: Arend van Spriel <arend.vanspriel@xxxxxxxxxxxx>
> >
> > Arend, let me ask one more question before getting this patch pushed.
> > It's quite late (I spent quite some time on this), but maybe still
> > better than fixing it later.
> >
> > It seems the most common struct that is:
> > 1) Often passed as argument
> > 2) Often having it's own variable in functions
> > 3) Used when calling functions from different file
> > is struct brcmf_pub.
>
> That is true for the function above the bus layer. In sdio/usb/pcie we
> can probably get it, but it is less straight forward. Maybe there we
> just want to use dev_err() as the struct device is short at hand there.
Correct. For the bus level I mean to continue using dev_err() just
like started with the commits:
5cc898fbcb35 ("brcmfmac: modify __brcmf_err() to take bus as a parameter")
8602e62441ab ("brcmfmac: pass bus to the __brcmf_err() in pcie.c")
> > Now I started wondering if we really want to have bphy_err() accept
> > wiphy. Maybe it would match brcmfmac's design better to have
> > bphy_err(struct brcmf_pub, fmt, ...)?
>
> Just might, but you still want to expand that to wiphy_err() right?
Correct!
--
Rafał
