[PATCH 2/2] char: xilinx_hwicap: Fix warnings in the driver

Michal Simek michal.simek at xilinx.com
Fri Aug 11 05:31:36 PDT 2017


On 10.8.2017 20:16, Rob Herring wrote:
> On Fri, Aug 4, 2017 at 2:49 AM, Michal Simek <michal.simek at xilinx.com> wrote:
>> On 4.8.2017 00:32, Rob Herring wrote:
>>> On Fri, Jul 28, 2017 at 03:17:26PM +0200, Michal Simek wrote:
>>>> From: Nava kishore Manne <nava.manne at xilinx.com>
>>>>
>>>> This patch fixes the below warning
>>>>         --> Use #include <linux/io.h> instead of <asm/io.h>
>>>>         --> Use #include <linux/uaccess.h> instead of <asm/uaccess.h>
>>>>         --> please, no space before tabs
>>>>         --> Block comments use a trailing */ on a separate line
>>>>         --> Possible unnecessary 'out of memory' message
>>>>         --> Block comments use * on subsequent lines
>>>>         --> Block comments use a trailing */ on a separate line
>>>>         --> braces {} are not necessary for any arm of this statement
>>>>         --> DT compatible string "xlnx,opb-hwicap-1.00.b"
>>>>          appears un-documented
>>>>         --> DT compatible string "xlnx,xps-hwicap-1.00.a"
>>>>             appears un-documented
>>>>
>>>> Signed-off-by: Nava kishore Manne <navam at xilinx.com>
>>>> Signed-off-by: Michal Simek <michal.simek at xilinx.com>
>>>> ---
>>>>
>>>>  Documentation/devicetree/bindings/xilinx.txt |  2 ++
>>>
>>> It's preferred to split bindings to separate patches. No need unless you
>>> respin:
>>>
>>> Acked-by: Rob Herring <robh at kernel.org>
>>
>> thanks. Was there any outcome from that discussion to extract binding
>> out of kernel source code?
> 
> Well, the reason to split the patches is so the history of the
> filtered DT repository we generate from the kernel tree[1] looks
> saner.
> 

So many merge commits. It looks weird.

https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/log/

> As far as actually moving things out, no there's not been any
> movement. My biggest concern with moving things out would be the loss
> of kernel subsystem maintainers' review. Once it's a separate tree and
> not merged thru their tree, we'd loose their reviews and I don't have
> confidence that we'd be gaining reviews from other places. Though some
> subsystem maintainers merge bindings and don't look at them already.

ok.

Thanks,
Michal



More information about the linux-arm-kernel mailing list