Re: [PATCHv4] wlcore: add wl1285 compatible

[Rob Herring]

On Mon, May 22, 2017 at 10:21 AM, Sebastian Reichel
<sebastian.reichel@xxxxxxxxxxxxxxx> wrote:
> Hi,
>
> On Mon, May 22, 2017 at 05:44:24PM +0300, Kalle Valo wrote:
>> David Miller <davem@xxxxxxxxxxxxx> writes:
>> > From: Kalle Valo <kvalo@xxxxxxxxxxxxxx>
>> > Date: Mon, 22 May 2017 12:28:20 +0300
>> >
>> >> Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxxxx> writes:
>> >>
>> >>> Motorola Droid 4 uses a WL1285C. With differences between the
>> >>> chips not being public let's add explicit binding for wl1285
>> >>> instead of relying on wl1283 being very similar.
>> >>>
>> >>> Reviewed-by: Rob Herring <robh@xxxxxxxxxx>
>> >>> Acked-by: Kalle Valo <kvalo@xxxxxxxxxxxxxx>
>> >>> Acked-by: Tony Lindgren <tony@xxxxxxxxxxx>
>> >>> Signed-off-by: Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxxxx>
>> >>> ---
>> >>> Hi Dave,
>> >>>
>> >>> I previously send this in two patches, but its hard to apply without
>> >>> requiring multiple kernel releases (the driver must be updated before
>> >>> the DTS change). Since the actual change is not very complex Marcel
>> >>> Holtmann & Tony Lindgren suggested, that I send this directly to you
>> >>> in a single patch for inclusion into 4.12. This also means, that the
>> >>> remaining series can be queued normally for 4.13.
>> >>
>> >> I noticed that Dave set this patch to Awaiting Upstream state on his
>> >> patchwork:
>> >>
>> >> https://patchwork.ozlabs.org/patch/759042/
>> >>
>> >> Which makes me suspect that he is waiting me to apply this (as I
>> >> normally apply wlcore patches). Dave, should I actually take this patch?
>> >> What do you prefer?
>> >
>> > Anything that touches wireless drivers I defer to you, yes.
>>
>> Thanks, I'll take it then. Not sure why Sebastian was suggested to
>> submit this patch via your tree in the first place.
>>
>> https://patchwork.kernel.org/patch/9713645/
>
> Thanks. The idea was to get into early 4.12-rc to avoid merge
> conflicts in the droid 4 *.dts during 4.13 cycle. This strategy
> obviously failed :)

First, I'm not sure why you combined everything. A maintainer can just
as easily take a series as a single patch and we prefer binding doc,
dts and driver changes all separate.

Second, the dts changes could go thru arm-soc and the driver change
thru netdev. The binding doc can be thru either. There's no bisecting
dependency and things shouldn't break. It just won't all work until
you have both branches.

Rob