On Sun, Jan 29, 2023 at 01:11:32PM +0100, Jacopo Mondi wrote: > On Sun, Jan 29, 2023 at 12:40:03PM +0100, Krzysztof Kozlowski wrote: > > On 28/01/2023 12:27, Jacopo Mondi wrote: > > > Add the bindings documentation for Omnivision OV5670 image sensor. > > > > > > Signed-off-by: Jacopo Mondi <jacopo.mondi@xxxxxxxxxxxxxxxx> > > > --- > > > v6->6.1 > > > - Use additionalProperties: false for endpoint properties from > > > video-interfaces.yaml > > > - List 'remote-endpoint' among the accepted endpoint properties > > > now that we use additionalProperties: false > > > > b4 diff '20230128112736.8000-1-jacopo.mondi@xxxxxxxxxxxxxxxx' > > Could not create fake-am range for lower series v1 > > > > Can you send patches in a way it does not break out workflows? Why > > making our review process more difficult? > > Because it's a nit on a 10 patches series with no other changes > requested ? So? Think of patch series as an 'email transport' for your git branches. If you rebase your branch, that's a whole new branch to send. > What is difficult exactly ? In addition to 'b4 diff', if a maintainer is applying this series, for a v7 they just do: b4 shazam msgid-of-v7 For v6.1, they do: b4 shazam msgid-of-v6 git rebase -i ... <stop on patch 1> git reset --hard HEAD^ b4 shazam msgid-of-v6.1 git rebase --continue Which one makes the maintainer's life easier? If it's a CI job trying to apply and test this, there's no way it's going to do the second case. Rob
