Rafał Miłecki <zajec5@xxxxxxxxx> writes:
> On 16 July 2017 at 13:21, Ian Molton <ian@xxxxxxxxxxxxxx> wrote:
>> I've been doing some cleanups in the broadcome brcmfmac driver, trying to
>> understand how it works.
>>
>> I think this makes the driver a *lot* more readable.
>>
>> Of note:
>>
>> * Gets rid of the arbitrary and completely 1:1 mapping of
>> struct brcmf_{core,chip}_priv/struct brcmf_{core,chip} structures
>> which add unreadability whilst offering no real seperation.
>>
>> * The patch titled HACK - stabilise the value of ->sbwad in use
>> highlights an issue that is either bizarre undocumented behaviour or a
>> genuine bug - without datasheets, I dont know. Essentially the value of sbwad
>> is taken as the base address in several functions, even though it is subject
>> to change should other IO occur that moves the window offset
>>
>> Obviously this is a first cut at this and needs substantial cleanup itself,
>> however I wanted to get some idea of wether I should continue working on this.
>
> I looked at 4 random patches and none got any description. Not to
> mention their chaotic subjects. In this state I can't even review it.
> If you want to have some change accepted, you've to convince us it's
> needed. Work on cleaning your patches and resend them. You also need
> to signed off your changes.
And try to stick with max 10-12 patches per patchset rule. More than
that and it gets difficult for everyone (submitter, reviewers and
maintainers). And if you are a new with the subsystem, like you are
here, start with baby steps: send one patch, wait for it to get applied,
send two, wait, send four, wait etc. This way you learn how things work
without putting too much burden on the maintainers and things go forward
smoothly.
--
Kalle Valo
