archive mirror
 help / color / mirror / Atom feed
From: Ian Molton <>
To: "James Hughes" <>,
	"Rafał Miłecki" <>
Cc: "" <>,
	Arend Van Spriel <>,
	Franky Lin <>,
	Hante Meuleman <>
Subject: Re: RFC: Broadcom fmac wireless driver cleanup
Date: Mon, 17 Jul 2017 10:45:56 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 17/07/17 10:13, James Hughes wrote:

> As someone who is interested in any bug fixes to this driver (Device
> is used on Raspberry Pi3/0W and we have a number of issues reported
> which we are actively investigating), it would be very useful to more
> clearly split out any actual fixes vs simply tidying up (Yes, I agree
> the driver is mostly incomprehensible).

I don't think there are any actual *fixes* in this RFC series. Its all

The only issue I highlighted in my covering email - the patch titled
"HACK" was the only issue I uncovered thus far in that code. I dont know
the correct solution, although I can *guess* it, which is not good
enough, IMO.

If no-one has the docs for this chip, thats a bad state of affairs. Is
there anything circulating?

> Perhaps asking the
> list/maintainers for comments on any located issues/bugs fixes would
> be a useful starting point,

Thats *literally* what RFC means, is it not?

> along with ensuring the description gives a good explanation of what
> the suspect issue is.

Yes, absolutely - for a fully signed off series, or a particularly
complex bit of code, sure.

I think each of these patches is easily reviewable. None of them are
complex, just huge.

As yet, I have *zero* idea that the maintainers are interested in taking
the driver in the direction I'm going. It looks a LOT like a typical
corporate code-dump, and unless I'm convinced that sending carefully
polished patches is worth it, I don't see why I should put the effort in.

Trust goes both ways in this process. Give me a sign that I should carry
on with this work. If its got no hope of ever going upstream, all I'm
doing is wasting time.


  reply	other threads:[~2017-07-17  9:46 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-16 11:21 RFC: Broadcom fmac wireless driver cleanup Ian Molton
2017-07-16 11:21 ` [PATCH 01/21] net: brcmfmac: Write function depends on size of regs not types Ian Molton
2017-07-16 11:21 ` [PATCH 02/21] net: brcmfmac: Fix brain damaged fn parameter order Ian Molton
2017-07-16 11:21 ` [PATCH 03/21] bcmfmac: simplify brcmf_sdiod_abort Ian Molton
2017-07-16 11:21 ` [PATCH 04/21] brcmfmac: Do away with this abomination: Ian Molton
2017-07-16 11:21 ` [PATCH 05/21] brcmfmac: its ALWAYS 4 Ian Molton
2017-07-16 11:21 ` [PATCH 06/21] brcmfmac: Clean up SDIO IO functions Ian Molton
2017-07-16 11:21 ` [PATCH 07/21] brcmfmac: Split buff_rw function up + cleanup annoying bcmerror variable Ian Molton
2017-07-16 11:21 ` [PATCH 08/21] brcmfmac: Sanitise all byte-wise IO Ian Molton
2017-07-16 11:21 ` [PATCH 09/21] brcmfmac: tidy header a bit Ian Molton
2017-07-16 11:21 ` [PATCH 10/21] brcmfmac: Further SDIO addressing cleanup Ian Molton
2017-07-16 11:21 ` [PATCH 11/21] brcmfmac: cleanup horrid offsetof() mess Ian Molton
2017-07-16 11:21 ` [PATCH 12/21] brcmfmac: Fix awfully named #define and crap multi-stage if...elseif clause Ian Molton
2017-07-16 11:21 ` [PATCH 13/21] brcmfmac: HACK - stabilise the value of ->sbwad in use for some xfer routines Ian Molton
2017-07-16 11:21 ` [PATCH 14/21] brcmfmac: Get rid of hideous chip_priv and core_priv structs Ian Molton
2017-07-16 11:21 ` [PATCH 15/21] brcmfmac: Simplify chip probe routine Ian Molton
2017-07-16 11:21 ` [PATCH 16/21] brcmfmac: rename axi functions for clarity Ian Molton
2017-07-16 11:21 ` [PATCH 17/21] brcmfmac: HUGE cleanup of IO access functions Ian Molton
2017-07-16 15:16   ` kbuild test robot
2017-07-16 15:16   ` [PATCH] brcmfmac: fix boolreturn.cocci warnings kbuild test robot
2017-07-16 11:21 ` [PATCH 18/21] brcmfmac: rename ctx -> bus_priv Ian Molton
2017-07-16 11:21 ` [PATCH 19/21] brcmfmac: Remove repeated and annoying calls to brcmf_chip_get_core() Ian Molton
2017-07-16 11:21 ` [PATCH 20/21] brcmfmac: general cleanup Ian Molton
2017-07-16 11:21 ` [PATCH 21/21] brcmfmac: rename horridly named IO functions Ian Molton
2017-07-17  4:53 ` RFC: Broadcom fmac wireless driver cleanup Rafał Miłecki
2017-07-17  9:13   ` James Hughes
2017-07-17  9:45     ` Ian Molton [this message]
     [not found]   ` <>
2017-07-17 10:38     ` Rafał Miłecki
2017-07-21 15:29   ` Kalle Valo
2017-07-17 12:41 ` Arend van Spriel
2017-07-17 15:56   ` Ian Molton
2017-07-17 17:40     ` Ian Molton
2017-07-17 16:18   ` Ian Molton
2017-07-17 16:20   ` Ian Molton

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:

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

  git send-email \ \ \ \ \ \ \ \ \

* 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).